A patchy Apache a-patchin: HTTP server gets fix for worrying root access hole Apache HTTP Server has been given a patch to address a potentially serious elevation of privilege vulnerability. Designated CVE-2019-0211, the flaw allows a "worker" process to change its privileges when the host server resets itself, potentially allowing anyone with a local account to run commands with root clearance, …
The master process has to in order to bind to port 80, traditionally (i.e. if you don't run it on a high port and have the front end firewall forward port 80 to it). I believe they are saying the unprivileged child process can gain execution in the parent context, and to do that you just need a vulnerability in whatever the child does e.g. an over flow in mod_php or whatever.
it's generally possible to use firewall+nat rules to re-direct port 80 to 8080 [and vice versa for the return traffic] for communications that appear to be on port 80 to the outside world...
might also be useful for running in some kind of jailed or VM process, where you actually listen on localhost but re-direct incoming ports accordingly. And yeah you could run it NOT as root.
(since it's an obvious thing, probably already being done in many places)
icon, because, obvious thing is obvious
pretty much what _I_ was thinking. I think the default for the 'ports' version on FreeBSD runs apache as 'www' and not root. It uses the 'httpd.conf' file to specify.
it looks, though, that the main process that calls all of the worker bees still runs as 'root' by default.
I expect you could still run the main process NOT as root... not sure what you'd win/lose by doing that.
Each account get's it's own Docker image and the host takes care of confinement ?
User namespaces help achieve that, but they don't seem to be as widespread as I hoped.
Most don't use that facility, and on top of that also run containers which run effectively as root (albeit inside a user namespace, but there have been CVEs to bust out of it).
When there's a will, there's a way.
Shared web hosting existed before Docker and other containerization packages, you know. Some providers take a long time to change how they do things. There's a lot of cost and potential disruption involved, and little benefit visible to their individual customers.
Yes, even when httpd first trotted out of CERN we had chroot, but chroot was a clumsy mechanism at best and techniques for escaping chroot jails are well-known. And while some POSIXy OSes have proprietary userspace-partitioning mechanisms, their non-standard nature is a big impediment to adoption.
Fol says that the vulnerability is triggered when the host server performs its daily restart routine, usually at 0625.
A startling claim. I don't think a daily restart routine is *that* usual: the default log rotation is weekly! I expect he was describing how he runs his server, and the reporter thought he meant standard practice. The point about the restart is that the vulnerability happens when both old and new processes are running, in the overlap that serves to provide continuity of service for users connecting to the server.
The reporter rightly points out that this relies on running in-process code. Not external code such as CGI or PHP-FPM. Permitting untrusted users to run in-process code is scary on many levels, though not unknown: Fol's demo exploit runs under mod_php, which I don't think anyone recommends nowadays in the era of PHP-FPM.
On the Ubuntu systems that I see it is exactly what Fol says: apache rotates logs daily, and logrotate runs off cron.daily which is run at 6:25 (/etc/crontab).
On Fedora the rotation is more complex (logrotate runs from anacrontab that has random delay, etc.). Logrotate configuration does not specify daily, but logrotate does run daily.
An Apache VirtualHost configured with something like:
CustomLog "|/usr/bin/rotatelogs /path/to/log 3600" LogFormatName
... doesn't need logrotate, or to have the Apache process restarted so often - and still gets hourly logs. The only good reason to restart it is if it needs to, due to a configuration change or - for one with embedded code like mod_perl2, for a code update.
Shame that nginx doesn't offer the same :/
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
