Recently, Charles Fol blogged about his privilege escalation bug in Apache, CVE-2019-0211, aka “CARPE DIEM” (seize the 0day, comrades!). This affects Apache HTTP Server versions 2.4.17 through version 2.4.38 (from October 9, 2015 to April 1, 2019).
Why is it cool? Exploiting this bug allows for escalation from the meager privileges of an Apache worker task (which usually runs as www-data) to root, which is pretty cool on its own. But what makes this blog extra cool is that the author also dropped a local PHP code execution 0day to demonstrate the Apache vulnerability. The write-up and commented PoC code are basically like brain candy for anyone with a taste for exploitation.
Yes, but: There are some non-trivial requirements to successfully exploit this. First, the attacker needs an initial foothold to execute arbitrary PHP (e.g. WordPress 0day), which can be assumed in shared hosting environments — but for other environments, this likely requires exploitation of some other remotely reachable vulnerability, like a file-inclusion bug. Attackers will probs be annoyed that it operates on a schedule — the `logrotate` utility gracefully restarts Apache (using `apache2ctl graceful`) daily at 06:25, so hackers must bid farewell to their plans to sleep in.
What’s at risk? This is indeed a scary situation for shared hosting providers that provide their services purely off of Apache configuration to split up tenancy (e.g. capsule8.edu/~kelly sort of pages or host header configs). From an OS perspective, anyone using RHEL is safe, but not RHSCL users. Ubuntu 16.04 and later is affected, but patches are already available. Debian jessie users are safe, as are those using stretch with the security repo — but not those using buster, Debian’s testing distro.
Well, actually: This weirdly makes a case for container isolation as a security boundary, although we def don’t recommend treating isolation as a security property in general. If those running Apache alongside other services used containers instead of using Apache’s virtual hosting, the attacker would need a kernel exploit to achieve the same outcome as this bug (and if you had a kernel exploit, you wouldn’t bother with this bug anyway). If each service received a container, even if an attacker escalated privileges through Apache to root, they would just be emperors of a tiny container island rather than compromising all the things.
The bottom line: If you use a shared hosting provider that is vulnerable to this bug, you should be saying “CARPE DAYUM,” because an attacker could find the motivation to jump through the necessary hoops if many juicy instances are the prize. If you’re just worried about it for yourself, make sure to patch. If you’re a Capsule8 customer, our default detection content for webservers catches this, so you need to do absolutely nothing.
The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.