Slashdot Mirror
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."
"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."
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...
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.
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.
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.)
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*.