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."

Comments

Re: 1996 called

[Anonymous Coward]

Um apparently the internet didnt get that memo because apache is still the most popular webserver.

Not all run it as root ...

[kbahey]

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.

Well, on Ubuntu and derivatives, Apache does not run as root. It runs as the user www-data.

So this applies to some Unix/Linux systems, not "most".

Re:Not all run it as root ...

[Wrath0fb0b]

you need root privileges to bind to port 80

Common sense would indicate that in that scenario you either

• 1. Get the socket as early as possible in startup then setuid(2) yourself to a user with lower privileges (and chroot yourself, while you are at it) before answering any requests
• 2. Failing that, run on a high numbered port and have iptables forward you traffic from 80, which is a specific instance of the more general strategy: run as little code as possible at high privilege

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.

Re:Not all run it as root ...

[Anonymous Coward]

On most systems, the the worker processes run as "apache" or some other unprivileged user, but there is a parent process which still runs as root (you need root privileges to bind to port 80).

Since both debian and redhat based systems do not work that way, and those groups are "most", you are not correct.

The initial "parent" process runs as root only to bind to the ports, then drops privileged to a specified user (www-data, apache, whatever), and after that it launches the worker processes which load modules such as mod-cgid and mod-digest.

While having root it isn't possible for CGI scripts to run. By the time it is possible there is no process in the chain that has any privileges above the specified UID.

That doesn't make this CVE a non-threat, but the threat isn't to the full system, just everything related to hosting.
On a shared web host you can still manipulate other users files which the web server can access.

Possibly the primary virtual-host as well depending if those files are editable by www-data or are read-only to all but root. That would also possibly limit system provided CGI scripts, as those are typically 755 root:www-data
But I have seen installations where even /var/www is fully owned by www-data and would be at risk.

Any database would probably be at enough risk for it to not matter.
There is little difference between full root to the SQL server, and having the user credentials for each and every user database within, at least if you intend to copy or delete the data.
The attacker may be unable to manipulate credentials (IE add/remove accounts), but since they would have the credentials used by the user scripts that would be little comfort to everyone else.

Re:Not all run it as root ...

[DamnOregonian]

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.