Apache Web Server Bug Grants Root Access On Shared Hosting Environments (zdnet.com) 85
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."
Re: 1996 called (Score:2, Informative)
Um apparently the internet didnt get that memo because apache is still the most popular webserver.
Re: (Score:2)
Some people are fundamentally incompetent and clueless. To them new=better, which is pretty irrational.
Re: (Score:2)
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.
Re: 1996 called (Score:4, Interesting)
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.
Re: (Score:1)
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
Re: (Score:2)
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.
Re: (Score:2)
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 fuckin
Re: (Score:2)
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 o
Not all run it as root ... (Score:4, Informative)
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".
Re: (Score:1)
Who runs their web server as root? Anybody who wants to run it on port 80. Apparently people here don't understand how it works. The base apache process starts up using the root user (which is required for opening a port below 1024 by the way) and then it creates subprocesses that run as 'apache' or 'www-data'.
Re: (Score:2)
I'm sure on modern bullshit distros like Ubuntu that systemd is involved somehow. That or some container nonsense.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
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 [freebsd.org] can control this. On Linux SELinux can do the same thing.
Re: (Score:2)
Re: (Score:2)
Linux != Unix. (although I suspect the summary is wrong). Does anyone run Unix these days?
Mac OS is certified UNIX (tm). Solaris. See BSD (Score:3)
> 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 i
Re: (Score:2)
Last I knew, they ran a Mach kernel. When did that change to a UNIX/ATT one?
3,700 pages of detailed requirements define Unix (Score:4, 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... [opengroup.org]
Re: (Score:3)
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.
True. I started to mention that (Score:2)
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.
Re: (Score:2)
This is the case in just about every *nix, even OSX.
In OSX, for example, pselect() is implemented on top of select().
Re: (Score:2)
I don't know enough about the topic to say much more intelligently. My name is in the kernel changelog only once.
I do notice that all Lamborghini Countach kit cars are built on Fieros, none are built on on VW bus, or a Corolla. As you said, it's much easier when the source is like the target in basic structure.
As to native, I suppose it also depends to some extent on the native source environment. If you had a true micro-kernel, perhaps in an academic setting, putting a lot of functionality in libraries wou
Re: (Score:2)
The fact that (near) POSIX compliance is offered by Cygwin's libraries doesn't make it emulated, any more than OSX implementing (emulating?) pselect inside of libc on top of the kernel's select.
My name is not directly in the kernel sources, I do however have a CVE for a Linux kernel exploit, a bionic userspace exploit, and my name is on several jailbreaks of the early iPhones, and I am, AFAIK, the first person to ever break the
Re: (Score:2)
> several jailbreaks of the early iPhones ... The first person to ever break the firmware RSA signature protection on a cell phone (V3 RAZR)
That's very cool. I've worked in security for many years, and I have a pretty good understanding of cryptography, but always from a defensive standpoint. I very, very rarely break anything. Do you happen to have a write up of how you want about doing that, in a practical sense?
Over 90% of my time thinking about how people might break things is theoretical, what one t
Obviously time for me to sleep (Score:2)
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.
Re: (Score:2)
People posting writeups of how to use it a year later [dotkam.com]
I actually never did do a write-up of this particular exploit, so this is a first. It was also while I worked fast food, and before I had any idea how professional technical world worked, so I didn't ever make source available either. I was 23 at the time. My later work was much better and more publicly documented.
Well, I didn't break RSA's encryption, of course. I'm no mathematician or cryptanalyst.
But back in 2006, RSA signed f
Re: (Score:2)
Very cool, thanks for explaining that. Makes sense. Doing it as an exception was clever.
> This was actually my first time using an ARM processor, and they didn't really have tools widely available for working with them. I did my reverse engineering, as well as my modifications to the unprotected exploit bootloader with the actual ARM docs.
You're not easily intimidated are you? :)
Re: (Score:2)
Deployed actual UNIX systems that run apache are irrelevant, statistically.
They meant *nix.
Re: (Score:2)
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).
Re: (Score:1)
I thought the parent process was supposed to start up, bind port 80, then drop privileges before it started forking worker processes. By the time the worker processes are running there should be no root process to escalate to.
Re:Not all run it as root ... (Score:5, Informative)
Common sense would indicate that in that scenario you either
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 [cmu.edu] 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 [cr.yp.to].
What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.
Re:Not all run it as root ... (Score:5, 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.
Re: (Score:2)
And why didn't the Apache shim call setuid to remove its root privileges after doing what it needed to do?
I get that IPC across privilege boundaries is hard. You can either try hard to do it right, or you can take the more pragmatic approach of not doing it at all.
Re: (Score:2)
First off the top of my head, is graceful HUPs. Only a privileged process may bind sockets to listening ports, or read privileged files, meaning absent a privileged master process, you have to completely respawn the process (and incur the downtime of it re-reading its configs, certificates, etc.)
You can either try hard to do it right, or you can take the more pragmatic approach of not doing it at all.
I don't see how punting the secure privilege-crossi
Re: (Score:2)
OK, but those sockets can be bound and those files read before dropping privileges. Those things should be considered fixed for the lifetime of the process anyway.
In order to change config? Is this really a proposal that we need to incur increased security surface of a root-process for the trivial convenience of being able to change th
Re: (Score:2)
OK, but those sockets can be bound and those files read before dropping privileges.
Yes, we know. You can't undrop your privileges, though.
Those things should be considered fixed for the lifetime of the process anyway.
As I tried to explain, that's where you, and the designers of most of the services that run the web (apache, nginx, postfix, etc) disagree.
In order to change config? Is this really a proposal that we need to incur increased security surface of a root-process for the trivial convenience of being able to change the configuration of a daemon on the fly instead of just reloading it?
A proposal? It's the status quo... You're the one presenting proposals here. I'm the one explaining why they've been rejected.
The principle of least privilege is real. There has to be security surface area in the kernel, no need to just add to the attack surface unless it's absolutely necessary for a critical function.
Ah yes, but we were discussing pragmatic approaches, weren't we? Don't use ideals and principles in a discussion about pragmatism, it's means you've lost right out the gate.
Ignoring that, of
Re: (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 spe
Re: (Score:2)
I find it so funny when morons "correct" me.
From a CentOS 7 system: .....: /bin/systemctl start httpd.service /usr/sbin/httpd -DFOREGROUND /usr/sbin/httpd -DFOREGROUND /usr/sbin/httpd -DFOREGROUND
$ sudo service httpd start
[sudo] password for
Redirecting to
$ ps -Af | grep [h]ttpd
root 21827 1 0 22:47 ? 00:00:00
apache 21829 21827 0 22:47 ? 00:00:00
apache 21830 21827 0 22:47 ? 00:00:00
apache 21831 21827 0 22:47
Re: (Score:2)
Personally, I'd rather have one process running as root than to have a hard requirement to start up a process as every possible user that could own a process.
It is sad the state of technical knowledge on slashdot these days. There was a time when a random slashdot cowherd was expected to understand the basics of system administration!
Re: (Score:2)
This isn't new.
Some years ago, I had some moron disputing the way a fresh installation of mysql started on CentOS/RedHat. The moron accurately described how things work on Debian (and Debian-derived distros), but, even though I pasted the exact commands and responses from a CentOS system that showed my point, the moron kept disputing it.
Re:Not all run it as root ... (Score:4, Interesting)
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.)
Re: (Score:2)
Well, on Ubuntu and derivatives, Apache does not run as root. It runs as the user www-data.
Wrong. It starts as root, then forks as www-data for each request. https://muras.eu/2017/12/06/ap... [muras.eu]
Re:Not all run it as root ... (Score:4, Interesting)
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.
Apache? (Score:2)
Re: (Score:3)
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.
Re: (Score:2)
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.
It's a fucking than. Newbies who read your post will create these garbage .htaccess crap files.
Re: (Score:2)
Assuming you don't create an XSS vulnerability with the redirect forwarding server.
If they can't get this much right....
Re: (Score:2)
Besides the security implications, it's also inefficient to check every folder for the file when it is browsed.
:|
I don't know what else to say to that. Of the dozens of syscalls that are performed on a single request, the fstat(.htaccess) for the path components aren't the painful ones. particularly because those dnodes are likely cached by the VFS.
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.
Ya, that's one pretty egregious example of using the wrong tool. I agree you shouldn't use a .htaccess where a .htaccess isn't well suited.
You probably shouldn't also assume that all scenarios suffer the pitfalls of the worst-case.
Is systems administration dying?
Re: (Score:2)
Re: (Score:2)
People that want a thinner front end use Apache Traffic Server these days.
And before that, you just learn how to write an apache config file and turn off what you don't use, and suddenly it is fast. ;)
Re: (Score:2)
That doesn't really address this problem, though.
Re: (Score:2)
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.
Nope. "Working at a data center" does not "make [you] any kind of expert or anything."
Being competent enough to have already RTFM would imply that you may be at least minimally competent. But the manual would explain a wide variety of circumstances that leave you with a root process that is used to spawn more processes. If you were an expert you'd already have used all that stuff in all the different configurations, from one BOFH to the next. And you'd also know that under the most common usage scenarios, t
Re: (Score:2)
Though to be fair, we hire lots of people who work in our datacenters who don't know the word root from the holes in their asses.
Someone's gotta sweep the floors.
bullshit scare (Score:1)
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.
Re: (Score:2)
The real reason it not an issue with over 99.999% of web servers is that few people are still using 90's style shared servers with no virtualization or sandboxing.
If you're using a cheap web server that is protected merely by the unix user controls, my goodness, you should shop around. Seriously. Are you really really really sure that you need a webserver, but can't afford $5/month for a VPS?
In 1998, you might have to subject yourself to that if you wanted the price that low. But virtualization lowers the c
Re:bullshit scare (Score:4, Interesting)
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*.
Re: (Score:2)
Why do people take shared hosting over a VPS? Simply because the control panel is simpler to operate.
This isn't just wrong, it is dangerously stupid and ignorant.
Re: (Score:2)
Re: (Score:2)
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.
Re: Stop using open source server software!!! (Score:2)
Yeah there's no way to be anonymous on the internet.
Re: (Score:2)
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.
Re: Stop using open source server software!!! (Score:2)
Re: (Score:3)
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
Re: (Score:2)
I'm not sure the hairs you're splitting were quite wide enough to be split.
Re: (Score:2)
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.
Well at least I know we aren't affected by this (Score:1)
... as our apache instances are much much older than the affected versions. Phew! :')