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."
Um apparently the internet didnt get that memo because apache is still the most popular webserver.
Phew, good thing this is only a problem on shared hosting environments. ðY'
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.
Not everyone is using nginx nowadays?
Slashdot, fix the reply notifications... You won't get away with it...
I've never seen apache running as root.
I guess working at data center for the last decade doesn't make me any kind of expert or anything though.
Anybody running Apache these days is running Apache as its own user ("www" or "apache" depending upon your flavor of Unix). So this really is not an issue with 99% of most web servers. If you're running Apache as root, you're an idiot.
Some people are fundamentally incompetent and clueless. To them new=better, which is pretty irrational.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
> 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.
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".
You started too far down the tree. Debian also uses www-data
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...
When it requires already having a user account on the server, it isn't really a secret backdoor. It is more like kicking in the door of the server cage next to you; they're going to know who did it.
Um apparently the internet didnt get that memo because apache is still the most popular webserver.
That's not the presumed implication.
The joke is, nobody uses a shared stack with a web config running as an apache module anymore. Each user on a modern shared system has their own virtualized private OS. Unix users and groups are good for managing the ownership of files between various partially-trusted users, but it is not a reasonable basis for any sort of serious security.
Of course everybody is still running apache. But on the modern stack, you can only root yourself with this.
Yeah there's no way to be anonymous on the internet.
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.
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)
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.
... as our apache instances are much much older than the affected versions. Phew! :')
Yeah I started to say "system interfaces, which can be provided by the kernel or libraries", but that paragraph was long enough already.
It would be rather difficult to make a Unix system using a kernel that wasn't designed to be at least Unix-like, though. You'd probably end up with either emulation or at least something like Wine, it would be non-native. The Linux kernel and the typical Unix system is designed to be like Unix, and therefore it's easy enough to make a Linux system comply.
I'm not sure the hairs you're splitting were quite wide enough to be split.
5 shills, buddy. You're on slashdot talking shit... in defense of your work?
Dude, like, shut the fuck up and get back to work, don't shill about your shitting 90s hosting service and how being a small hosting fish guarantees you're doing things right and that customers are benefiting by choosing you.
Yeah fucking right! They should choose somebody who knows enough about the technology not to push old, insecure hosting stacks and then use false equivalency to try to create a scare about wordpress, as if using shitty shared hosting protects you from that or something. It doesn't. So if you use shitty wordpress, you get p0wned from that, in addition to already getting p0wned because you used shitty shared hosting without virtualization.
Don't forget to include a comment with your comment next time.
And also, is the situation "on the internet" or "when spending money electronically?" Are those automatically the same thing?
We know you don't know, and don't have any thoughts, because you'd have included at least one thought in your comment.
I'm pretty sure I'm more qualified to opine than you are. I have already written a POC for this exploit. I have my own CVE.
If you've read slashdot long enough, you've actually read about it.
I was splitting hairs, I was correcting a very incorrect assertion on your part.
I don't think you know what the word shill means.
There's so much wrong with your claims that I don't know how it doesn't embarrass you.
You actually claimed that a VPS takes less resources than shared hosting. That's literally the stupidest fucking thing I've read today.
Please, go on, enamor us with your wizardly computer science knowledge.
You're a fucking idiot.
As I was drifting off to sleep I wrote:
> Not emulated, we know what Cygwin stands for.
As I was writing "Cygwin", half my brain was apparently thinking "Wine". *Wine* is not an an emulator. Lol.
You don't fucking know, because your service is still using 90s tech. Why would you have any idea what the difference in resources is? That is a ghetto service level, you obviously didn't invest in a modern setup and then find that the old way was better.
But I'll throw you a bone. VPS takes less resources because most of the instantiations are not actually in use most of the time. Containers not in use get parked, and transparently restored when you connect to them. It sounds "literally the stupidest fucking thing [you've] read" simply because it is true, and a technical detail. Of course it sounds stupid to you. You're providing 90s shared hosting, in 2019, and you're not only shameless, you're actually trying to shame others. Others who provide containerized services.
My clients sure as fuck would rather have the safety of modern containers than the shit like in the story where anybody with half a clue who is hostile to your clients can p0wn your shit and attack them. When your clients are protected solely by hoping that the system doesn't have any undisclosed unix user escalation vulnerabilities, you're totally fucked at all times. That is how often that particular type of exploit has been in the wild continuously for decades. The user system is pretty good, for what it is, but it doesn't provide the protection needed for shared hosting. Duh.
You don't fucking know, because your service is still using 90s tech. Why would you have any idea what the difference in resources is? That is a ghetto service level, you obviously didn't invest in a modern setup and then find that the old way was better.
LOL. Mmmmk.
Being unable to disclose my employer, all I can say is that you have no idea what the fuck you're talking about.
But I'll throw you a bone. VPS takes less resources because most of the instantiations are not actually in use most of the time.
How irrelevant.
A VPS has higher overhead, period. It's unavoidable.
It requires splitting off the kernel namespace and adding more entries to the scheduler. It is literally twice as expensive to operate 2 apaches, than one. It is again, unavoidable.
Containers not in use get parked, and transparently restored when you connect to them.
Yes, and processes that are waiting on an accept() are also sleeping.
It sounds "literally the stupidest fucking thing [you've] read" simply because it is true, and a technical detail. Of course it sounds stupid to you. You're providing 90s shared hosting, in 2019, and you're not only shameless, you're actually trying to shame others. Others who provide containerized services.
No, it was the stupidest thing I'd read that day because it was not only factually incorrect, but logically incoherent. Everyone who reads your logic train is now stupider for having to try to figure out if there was any possible way you could be right.
My clients
Stop. They're customers, and they want fries with that.