Slashdot Mirror
Apache Web Server Bug Grants Root Access On Shared Hosting Environments (zdnet.com)
An anonymous reader quotes a report from ZDNet: This week, the Apache Software Foundation has patched a severe vulnerability in the Apache (httpd) web server project that could --under certain circumstances-- allow rogue server scripts to execute code with root privileges and take over the underlying server. The vulnerability, tracked as CVE-2019-0211, affects Apache web server releases for Unix systems only, from 2.4.17 to 2.4.38, and was fixed this week with the release of version 2.4.39. According to the Apache team, less-privileged Apache child processes (such as CGI scripts) can execute malicious code with the privileges of the parent process. Because on most Unix systems Apache httpd runs under the root user, any threat actor who has planted a malicious CGI script on an Apache server can use CVE-2019-0211 to take over the underlying system running the Apache httpd process, and inherently control the entire machine.
"First of all, it is a LOCAL vulnerability, which means you need to have some kind of access to the server," Charles Fol, the security researcher who discovered this vulnerability told ZDNet in an interview yesterday. This means that attackers either have to register accounts with shared hosting providers or compromise existing accounts. Once this happens, the attacker only needs to upload a malicious CGI script through their rented/compromised server's control panel to take control of the hosting provider's server to plant malware or steal data from other customers who have data stored on the same machine. "The web hoster has total access to the server through the 'root' account. If one of the users successfully exploits the vulnerability I reported, he/she will get full access to the server, just like the web hoster," Fol said. "This implies read/write/delete any file/database of the other clients."
"First of all, it is a LOCAL vulnerability, which means you need to have some kind of access to the server," Charles Fol, the security researcher who discovered this vulnerability told ZDNet in an interview yesterday. This means that attackers either have to register accounts with shared hosting providers or compromise existing accounts. Once this happens, the attacker only needs to upload a malicious CGI script through their rented/compromised server's control panel to take control of the hosting provider's server to plant malware or steal data from other customers who have data stored on the same machine. "The web hoster has total access to the server through the 'root' account. If one of the users successfully exploits the vulnerability I reported, he/she will get full access to the server, just like the web hoster," Fol said. "This implies read/write/delete any file/database of the other clients."
Common sense would indicate that in that scenario you either
What's not an answer is "run the actual process as root while serving user requests". It's shocking that this is even considered remotely like a possible solution.
What's doubly galling is that there is a loooong unix history of applications that require far more intrusive privileges using both or these techniques -- either getting what they need and immediately dropping to the position of least privilege or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC. So it's not like they couldn't draw on those examples or literally just copy-pasta DJB's code.
What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.
What's not an answer is "run the actual process as root while serving user requests".
Good thing that's not what's happening here.
It's shocking that this is even considered remotely like a possible solution.
It's also shocking when people offer an uninformed opinion.
or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC.
This is the funniest quote here, because that's exactly how apache works.
What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.
The vulnerability here is in how the privileged parent process handled IPC with the unprivileged children. IPC between privileged and unprivileged processes is always dangerous without formal verification and lots of eyeballs making sure you parse that IPC safely.
They got bit here. They fixed where they got bit.