
Apache web server bug grants root access on shared hosting environments - praveenscience
https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/
======
3ch0
Found this, looks like a more detailed writeup of whats going on.
[https://cfreal.github.io/carpe-diem-cve-2019-0211-apache-
loc...](https://cfreal.github.io/carpe-diem-cve-2019-0211-apache-local-
root.html)

~~~
ec109685
This part is concerning:

> Apache's team has been prompt to respond and patch, and nice as hell. Really
> good experience. _PHP never answered regarding the UAF._

~~~
hannob
FWIW I reported it to PHPs bugtracker:
[https://bugs.php.net/bug.php?id=77843](https://bugs.php.net/bug.php?id=77843)

I expect that it'll be fixed, not not handled as a security issue, as it
doesn't fit within PHPs model of security vulns.

~~~
jimktrains2
> This looks like it requires specially crafted code, therefore not a security
> issue.

I'm not sure how I feel about such a response. Many exploits require odd, but
valid code, and more often than not it exists out there.

Also, it feels weird for this to be tagged as a JSON issue?

~~~
jsight
Basically they don't consider the engineer exploiting the interpreter to be a
security vulnerability. That seems a bit dubious, but I can see where they are
coming from in treating the script author as a trusted party.

------
josteink
> 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?

~~~
SEJeff
> 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!)

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

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

------
raintrees
Wouldn't SELinux disallow writing to the cgi folder, unless that attribute
were explicitly set?

~~~
giobox
Almost everywhere I’ve worked ends up turning off Selinux rather than learn
how to actually configure/use it properly, which of course is ridiculous when
it’s not actually that hard to learn or configure at all generally, but such
is the reality of many places it seems.

------
btown
For something this severe, there doesn’t appear to have been coordination with
large shared hosting providers to ensure the patch was applied before public
disclosure of a PoC. Is there a system in place for this?

~~~
foobarbazetc
It doesn’t effect CentOS 7, which is what most hosting providers run on.

~~~
equalunique
How do you know it doesn't affect CentOS 7? Please provide a citation for your
claim. :)

~~~
ihattendorf
I'm not the person you're replying to, but:

[https://access.redhat.com/security/cve/cve-2019-0211](https://access.redhat.com/security/cve/cve-2019-0211)

My guess is because they're on an older version (2.4.6) that isn't affected.
But that all depends on what patches have been applied to the RHEL/CentOS
version.

------
jondubois
>> less-privileged Apache child processes (such as CGI scripts) can execute
malicious code with the privileges of the parent process.

Vulnerabilities always seem to be related to CGI scripts somehow.

~~~
tyingq
Something that makes the cgi process not a child of the Apache process
wouldn't be subject to this. Like a fcgi process.

~~~
rbritton
I'm surprised FastCGI isn't more popular for that reason. Using PHP as an
example, Apache + mod_php executes all code under Apache's user/group. If,
instead, you use PHP-FPM, you can lock down the execution environment much
more.

PHP-FPM supports an arbitrary number of named pools, each of which may be
configured with its own user/group pair. Ideally, each virtual host gets its
own pool.

e.g.,

    
    
        [poolname]                                                                                                                                                 
        user = poolowner                                                                                                                                          
        group = poolgroup                                                                                                                                         
         
        listen = /run/php/php7.2-fpm-poolname.sock                                                                                                                 
        listen.owner = www-data                                                                                                                                       
        listen.group = www-data   
        ...

~~~
dspillett
_> I'm surprised FastCGI isn't more popular for that reason._

FastCGI is more faf to configure where mod_php is more likely to be configured
out of the box. Most shared hosting environment are configured entirely out-
of-the-box as the market is so saturated and margins so low there is no way to
justify anything else. Potential customers who care much about security will
most likely be looking for their own dedicated server or VM instead so there
isn't really much of a market for a more secure shared host.

Also if packing as many users as possible into as little hardware as possible,
which is the only way to make any margin in shared hosting these days, you'll
find mod_php more efficient by this measure. You don't have a pool of
processes that only specific users can take advantage of, taking up an amount
of RAM (however small) each even when not actively in use.

So FastCGI tends to be used less. When I ran PHP I used it, usually as you
suggest one pool per vhost, but I was only hosting my own projects and some
bits for friends & family, so I didn't need to justify the setup effort
against any "bottom line".

~~~
regecks
I've noticed the opposite.

More people are starting to realize that FastCGI is one of the keys to good
and consistent performance (as much as PHP will allow, anyway) and are
recognizing that mod_php for the disaster that it is.

So now more and more popular environments support it - cPanel gained native
PHP-FPM support, and commercial shared web hosts are mostly using Litespeed
(drop-in replacement for Apache httpd that is evented and invented its own
FCGI-like called "LSAPI").

Not sure if I totally agree with mod_php being more efficient for a greedy
host either - attaching the PHP runtime to the threaded/forked httpd request
handler is very expensive.

You can set the per-pool minimum worker size to 0 with FCGI with a short
keepalive, which allows you to keep a low average per-tenant memory footprint,
but better performance when many requests arrive at once. That's also
basically what Litespeed does.

~~~
tyingq
_" one of the keys to good and consistent performance (as much as PHP will
allow, anyway)"_

I've found that caching any results of logic that's repeated per request makes
PHP pretty damn fast. I use apcu, it saves state with an mmap backed cache.

------
6xggd7
Who's still using Apache?

~~~
rkeene2
I use it. On purpose. It's a good general purpose web server and does a good
job.

~~~
neurobashing
It's also copiously documented and extremely well-understood. There will
always be bugs in software but you can usually fix problems quickly, there's
few surprises or gotchas. I trust it.

