Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apache Web Server Bug Grants Root Access On Shared Hosting Environments (zdnet.com)

Posted by BeauHD on from the open-access dept.

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

15 of 85 comments (clear)

  1. Re: 1996 called by Anonymous Coward · · Score: 2, Informative

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

  2. Not all run it as root ... by kbahey · · Score: 3, Informative

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

    --
    2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
    1. Re:Not all run it as root ... by Wrath0fb0b · · Score: 4, Informative

      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.

    2. Re:Not all run it as root ... by Anonymous Coward · · Score: 2, Informative

      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.

    3. Re: Not all run it as root ... by TheRaven64 · · Score: 2

      That's a terrible idea in a multi-user environment, because when the Apache process dies any other user can open that port (they may even open it accidentally) and now they get all of your web server traffic.

      On modern UNIX systems; however, it is possible to grant the permission to open specific low ports. For example, on FreeBSD the portacl MAC framework policy can control this. On Linux SELinux can do the same thing.

      --
      I am TheRaven on Soylent News
    4. Re:Not all run it as root ... by DamnOregonian · · Score: 3, Interesting

      You're killing us, smalls.

      Apache's parent process always runs as root.
      This is so that it can spawn the necessary privileged ports.
      Only children in fork/pre-fork models run as the unprivileged user, which is precisely what this CVE is about.
      Unprivileged fork/pre-fork workers that have had their code compromised can fuck with the scoreboard (chunk of shared memory between privileged parent, and unprivileged child) and get the privileged parent to run worker-supplied code before privilege drop after the fork.

    5. Re:Not all run it as root ... by DamnOregonian · · Score: 4, Informative

      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.

    6. Re:Not all run it as root ... by DamnOregonian · · Score: 3, Interesting

      Ya, the dude who "corrected" you is fucking insane.
      No version of apache has code that drops the privs of the master process, only the workers.
      It fundamentally breaks operations like HUPs (lest you decide that you want your apache configs readable by the workers.)

  3. Re:Apache? by MatthiasF · · Score: 2

    Using .htaccess is bad practice anyway. Besides the security implications, it's also inefficient to check every folder for the file when it is browsed.

    Better to redirect to a different webserver for 404s that can lookup the URL for broken links and send you back to the right URL, then create hundreds or thousands of .htaccess files.

  4. Mac OS is certified UNIX (tm). Solaris. See BSD by raymorris · · Score: 2

    > Does anyone run Unix these days?

    Yes, Mac is Unix. Not Unix-like, but actual UNIX (tm).

    BSD (Berkeley Standard Distribution) used to be called Berkeley UNIX. It *was* UNIX, and the Unix hasn't been entirely removed. Some of the original Unix code was oown source and FreeBSD was built with that open source portion of Unix at it's core. Since then, UNIX and the BSDs have evolved separately, of course.

    Solaris is real UNIX.

    So yeah, all those MacBooks are running UNIX. It's pretty handy to have a UNIX that is approved and supported by corporate IT departments.

  5. 3,700 pages of detailed requirements define Unix by raymorris · · Score: 3, Interesting

    The Mac OS *kernel* comes from AT&T via DEC and others. Anyway, thirty years ago, AT&T sold the Unix name, and 25 years ago it was transferred to the Open Group, so it's been 30 years since Unix and and AT&T parted ways, 25 years since the Unix name went open. The reason I say "the Unix name" is because when the name was originally sold and locked down, there were several different Unix operating systems. At least three, which were all Unix, all derived from the same code. One group kept the name, the Open Group via AT&T and Novell.

    In other words, it's kinda like asking "is Sierra actually Mac? I didn't know know Wozniak wrote it." Yes, new programmers can work on some software and it's still real. There have been 30 years of programmers between AT&T and modern Unix. It's still Unix.

    There is a 3,700 page set of detailed specifications called the Single Unix Specification. A Unix system is defined as an operating system which is certified to meet all of those specs. The spec includes things like a Bourne-shell derived /bin/sh called the POSIX shell, ncurses, and 1,123 kernel and library functions.

    Note the Unix spec describes (in detail) what a Unix *operating system* is, how it behaves and what it provides. Less than half of the spec deals with the *kernel*. The specs say the operating system must provide all of these different functions, which must work exactly as described. It does not specify *who* must write the functions. That's been true for 25 years. The pedigree of the kernel does not matter at all in terms of whether it's Unix. If you and I wrote an exact copy of Solaris Unix, so we ended up with the same operating system, that would be a Unix, if we got it certified showing we made a faithful copy - we met all specs correctly.

    As far as the pedigree of the *kernel* goes, back in the AT&T days, AT&T licensed DEC, Microsoft, and others to create Unix systems. There were three major Unix systems. OSF/1 was one of those, BSD was another. OSF/1 (Open Software Foundation 1) used a modified version of a kernel built, for Unix systems, based on BSD Unix code, called mach. Years later, more code from BSD, mach, and other sources in the NeXTSTEP operating system. When Apple bought Next, they replaced much of the kernel code from NextSTEP with code from a different, more direct, descendant of OSF, which had been renamed OSFMFK, then modified it extensively to create XNU.

    So yes there is some mach code in XNU. Mach was largely a reworking of kernel code from the Berkeley UNIX tapes. All of these kernels were designed for, and used in, Unix systems.

    A list of Unix (tm) operating systems can be found here:

    https://www.opengroup.org/open...

  6. Re: 1996 called by DamnOregonian · · Score: 3, Interesting
    You're mixing up shared hosting with a VPS. They are separate products, and both exist (I know, because my company sells both)

    With a VPS, obviously *you* can only root yourself, but more importantly, someone who has access to whatever the Wordpress exploit du jour is can root your VPS. Still problematic.

    The joke is, nobody uses a shared stack with a web config running as an apache module anymore.

    5 pinnocchios, right there.
    We host about 5000 domains on shared web hosting, and about 300 VPS instances.

  7. Re:bullshit scare by DamnOregonian · · Score: 3, Interesting

    Quit saying this. It simply isn't true.

    Your logic that you're using to justify this false claim isn't bad logic, it's just incomplete.
    Why do people take shared hosting over a VPS? Simply because the control panel is simpler to operate.
    Our shared hosting customers are often people with some family website or other personal website.

    The shared-hosting market is fucking *huge*.

  8. Re:Stop using open source server software!!! by DamnOregonian · · Score: 2

    This bug does not require a user account on the server at all. It does however require a second bug to work, as in an exploit in PHP or some other module that allows modifying the shared memory segment between the workers and the master.

    It's a pretty difficult vulnerability to exploit, really. It requires:
    1) some badly written php or something else that will either allow you to eval() client submitted code, or write it to disk and then request it.
    2) an exploit within the php (or equivalent) interpreter itself to allowed direct memory modification of Apache worker IPC shared data segment (Scoreboard).
    3) an eventual graceful restart of apache (probably next time logrotate runs)

  9. Re:3,700 pages of detailed requirements define Uni by DamnOregonian · · Score: 2

    Less than half of the spec deals with the *kernel*

    Technically speaking, the SUSv3, which OSX on Intel procs conforms to, doesn't specify kernel functionality at all. It does specify "system interfaces", but they can be handled by an entirely user-space libc layer.
    This is why Linux kernel based operating systems have been SUSv3 certified as well.