Hacker News Reader

Comment by josteink | Hacker News Reader

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

Maybe I am conflating things or mixing something up, but I was under the impression that it only used root-privileges to obtain access to restricted ports and immediately afterwords lowered its privileges lever to something sane/non-risky.

And if that is how it operates, then this exploit should not be effective.

Is that wrong? Have I been misled?

View on HN

> Because on most Unix systems Apache httpd runs under the root user

This hasn't been true for what, 10+ years? Apache runs as user www-data on Ubuntu/Debian and as user httpd on Redhat / SUSE based distributions.

You're entirely right, but this is a bit of embellishment on the part of the exploit author (even though it is serious!)

It actually starts as root, then drops privileges / setuids to www-data.

"this is a bit of embellishment on the part of the exploit author"

Apache is saying the same thing.

"In Apache HTTP Server 2.4 releases 2.4.17 to 2.4.38, ...code executing in less-privileged child processes or threads (including scripts executed by an in-process scripting interpreter) could execute arbitrary code with the privileges of the parent process (usually root)"

https://httpd.apache.org/security/vulnerabilities_24.html#CV...

Lots of people install from source and just sudo everything because that's all they know.

The vanilla APACHE_RUN_USER/_GROUP is daemon/daemon so they're fine. daemon and nobody are users that by definition have no permissions on the host.

It runs as wwwrun on SUSE based distros.

The worker processes that actually do all the rendering run as the user and group you’ve configured. The parent continues as root.

This exploit lets an unprivileged child worker (for example running mod_php on regular shared hosting clients' .php files) hack back into the root parent process and thus escalate from unprivileged to root.

I still don't get it. CGI scripts would run with reduced privileges. The CVE description says "code executing in less-privileged child processes or threads (including scripts executed by an in-process scripting interpreter) could execute arbitrary code with the privileges of the parent process (usually root) by manipulating the scoreboard"

What is the scoreboard?

It’s basically the list the master process keeps of the worker processes it has spun up. The workers can report back some stats that the master tracks about each. Apparently something in that report back process could be exploited to run arbitrary code.

Who on earth doesn't run CGI scripts, etc., as a separate user to the one that their apache workers run as?

Probably most people. Who uses setuid CGI scripts?

You can't really have a setuid "script" anyway. But you can, at the bare minimum, launch CGI scripts via suEXEC. This prevents them from being able to attack the httpd worker processes, since they won't be running as the same user.

Welcome to reality. Please leave your principles at the door, you won't be needing them here.

I think it's been very common for 15 years to use Apache's "suexec" to run each CGI process as the individual user rather than as a user related to Apache.

There's also suPHP which allows you to do the same thing for PHP processes.

Precisely. There's also PHP-FPM. I am astounded that people still rely on mod_php!

Would that actually mitigate this problem? It's not clear to me.

A process running as another user won't be able to modify the memory of the apache worker process.

While it might not be relevant to this particular issue (though it might, I didn’t dig too deeply), there’s a long standing history of running everything inline with Apache. I mean look at mod_php... sure we’ve all (hopefully) learned our lesson there, but it’s a hell of a hole to dig back out of as long as things keep working.

It’s one of the reasons I’m always suspicious any time I run into a company that runs Apache rather than nginx or one of the many other alternatives. There is absolutely nothing wrong with running Apache, but it always makes me wonder exactly why they are... is it because they’ve got this one app that won’t run on anything else because of crap like this? More often than not...

The parent process continues to run as root.

Why is it necessary?

The usual reason for this sort of design is so you can support loading a new configuration without having to restart the whole thing, if the new config might need you to do additional things that require privilege (maybe bind to new low ports, or read key files).

I would expect restart to bind to new ports. It's not something that should be supported on-the fly (it's good thing, of course, but not at expense of keeping root process). Reloading key files is useful, but I think that it could be implemented with other means (e.g. reload program which runs under root, could read those files and pass them via some kind of IPC).

Because, depending on your configured concurrency model, it may need to be able to spawn new processes/threads as other users, and this is not possible unless you have at least one process running with some privileges beyond that of the normal users. This usually means root. Even if not root, it needs to be a user/group privileged enough to be able to impersonate the other users, or it can't do its job.

The code running with greater privilege is kept to a minimum but at least some needs to be there, and this exploit potentially gives a route through to manipulate it.

FastCGI and similar can help here - it can push the creation of user specific processes away from Apache, making it harder to cross the barrier.

you can't bind to port 80/443 without being root unless you have cap_net_bind_service. so instead of using nat/caps you just spawn as root to bind.

Right, but there's no reason for the parent process to keep root privileges after binding to the privileged ports.

Thanks. I never used that feature, nor I ever heard of anyone using it. IMO there should be some configuration option to turn that feature off, which will allow to run all processes as a designated user. Or, if those users could be enumerated at startup, it could spawn one process for each user.

Reply on news.ycombinator.com