5 ms·
> 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-20
by josteink 8y ago
> 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?
- netsec_burn 8y agoThe parent process continues to run as root.
- vbezhenar 8y agoWhy is it necessary?
- mjw1007 8y agoThe 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).
- vbezhenar 8y agoI 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).
- dspillett 8y agoBecause, 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.
- merb 8y agoyou 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.
- kelnos 8y agoRight, but there's no reason for the parent process to keep root privileges after binding to the privileged ports.
- vbezhenar 8y agoThanks. 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.
- ams6110 8y agoI 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?
- chrismeller 8y agoIt’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.
- yrro 8y agoWho on earth doesn't run CGI scripts, etc., as a separate user to the one that their apache workers run as?
- tedunangst 8y agoProbably most people. Who uses setuid CGI scripts?
- yrro 8y agoYou 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.
- arbitrage 8y agoWelcome to reality. Please leave your principles at the door, you won't be needing them here.
- rkeene2 8y agoI 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.
- chrismeller 8y agoThe worker processes that actually do all the rendering run as the user and group you’ve configured. The parent continues as root.
- SEJeff 8y ago> 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!)
- icedchai 8y agoIt actually starts as root, then drops privileges / setuids to www-data.
- tyingq 8y ago"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#CVE-2019-0211 https://httpd.apache.org/security/vulnerabilities_24.html#CV...
- mchristen 8y agoLots of people install from source and just sudo everything because that's all they know.
- tannhaeuser 8y agoThe 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.
- Vogtinator 8y agoIt runs as wwwrun on SUSE based distros.
- 0x0 8y agoThis 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.