Apache Fixes Actively Exploited Web Server Zero-day (therecord.media) 34
The Apache Software Foundation has released a security patch to address a vulnerability in its HTTP Web Server project that has been actively exploited in the wild. From a report: Tracked as CVE-2021-41773, the vulnerability affects only Apache web servers running version 2.4.49 and occurs because of a bug in how the Apache server converts between different URL path schemes (a process called path or URI normalization). "An attacker could use a path traversal attack to map URLs to files outside the expected document root," the ASF team said in the Apache HTTP Server 2.4.50 changelog. "If files outside of the document root are not protected by 'require all denied' these requests can succeed. Additionally this flaw could leak the source of interpreted files like CGI scripts," Apache engineers added. More than 120,000 servers currently exposed online to attacks.
Great.... (Score:2)
Oh, great. I literally just set up a server with that version (it was the current version last week).
Re:Great.... (Score:2)
Seems to me that directory traversal bugs should be top of mind when doing QA on a web server.
Re:Great.... (Score:2)
Using such a powerful, full-blown web server, proxy, authentication tool, and other service provider is popular but remains dangerous. Smaller tools, with smaller attack survaces and well defined API's among their components, remain more robust and safer. Apache was veryeffective when first published, but as it became "httpd" its' grace and simplicity were lost in favor of unnecessary and unwelcome features which have become awkward to disable.
Mod parent up! This is a common web server bug! (Score:0)
Mod parent up. This is a common web server bug!
Re:Great.... (Score:3)
Update: Half an hour wasted because this line works in Apache 2.4.49 (and previous versions) but not in 2.4.50
# PHP plugin
LoadModule php_module "C:/apache24/php-8.0.11/php8apache2_4.dll"
Clue: Remove the quotes from around the file name
Re:Great.... (Score:2)
According to the linked article, it does NOT work on previous versions. I have 2.4.38. And indeed, if I try the example from a tweet in the article:
... ...
curl "https://my.example.com/whatever/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/etc/passwd"
I just get
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.
Re:Great.... (Score:0)
Use the package manager and then make sure automatic updates are working. The major distro package managers (apt, yum, etc.) already have patched versions of Apache in place and are deploying those updates globally over the next 24 to 48 hours.
Apache is fairly out of date these days given it can only handle about 120 simultaneous connections (by default and is controlled at compile-time rather than being a configurable setting) and each web browser connecting in will use 2-4 connections thereby limiting Apache to around 30-60 simultaneous users. If WebSocket is in the mix, then the Apache execution model is very severely outdated. Nginx or HAProxy as a frontloader to an Apache backend is a much better option and can handle anywhere from thousands to 10's of thousands of connections on a single system and helps to minimize vulnerabilities in Apache that come up.
Re:Great.... (Score:2)
Use the package manager and then make sure automatic updates are working.
On Windows?
Re:Great.... (Score:2)
You are putting a Windows computer on the public Internet...
Why?
(That's a rhetorical question. If you want to run a public-facing web server, run a decent Linux server distro as the host OS and learn how to manage it properly. Running Windows, even Server editions, as a public web server is asking for all kinds of trouble.)
Re:Great.... (Score:0)
You are putting a Windows computer on the public Internet...
Why?
They are more secure than Linux computers.
Re:Great.... (Score:1)
Time to infection of a newly installed Windows machine on the Internet has been in the single minutes [slashdot.org], faster than Windows Update can run.
2020-2021 Windows survival time data:
https://web.archive.org/web/20... [archive.org]
Re:Great.... (Score:2)
Amazing. I ought not to even be able to type this...
Re:Great.... (Score:2)
run a decent Linux server distro as the host OS and learn how to manage it properly.
I can't be bothered.
Running Windows, even Server editions, as a public web server is asking for all kinds of trouble.)
I've done it for the last decade (or more) and nothing bad has ever happened.
Re:Great.... (Score:-1)
Well that was dumb. Use Nginx. Apache is bloated hot garbage.
Nginx has had 31 vulnerabilities in 12 years. That's 2.6 vulns per year. The most ever is 4 vulns in a year.
Now look at Apache. 226 vulnerabilities in 22 years. That's over 10 vulns per year. Some years had 20 vulns!
Get off the sinking ship.
Re:Great.... (Score:0)
I just give the true facts, moron.
Editing, maybe? (Score:2)
"More than 120,000 servers currently exposed online to attacks."
Do the editors here actually DO anything?
Re:Editing, maybe? (Score:1)
Do the editors here actually DO anything?
This your first time reading slashdot?
Re:Editing, maybe? (Score:2)
I think the slashdot editors do something like this:
1. Get high.
2. Eat Munchies.
3. Click Approve.
4. Repeat.
Re:Editing, maybe? (Score:2)
Jealous?
Re:Editing, maybe? (Score:2)
No. I skipped the parts about all of the fun troll issues on slashdot. I probably don't want to deal with slashdot's issues whether I'm high and fed or not.
Containers (Score:2)
Re:Containers (Score:2, Insightful)
No.
Re:Containers (Score:2)
Containers are a symptom of dependency hell. Too many libraries and a development environment so convoluted that only the author can recreate it. So instead of fixing the problem it's now managed by containers.
Re:Containers (Score:0)
Containers are a symptom of dependency hell. Too many libraries and a development environment so convoluted that only the author can recreate it. So instead of fixing the problem it's now managed by containers.
Or just statically link everything. That works too given fact Linux is an impossibly fragmented disaster for software distribution.
Re:Containers (Score:0)
Or just statically link everything. That works too given fact Linux is an impossibly fragmented disaster for software distribution.
Let's hide all the dependencies! And then have to patch every hidden copy of vulnerable libraries! That I don't know exist!
Re:Containers (Score:2)
That's my understanding of what containers were originally designed for - restricted usage of system resources.
Re:Containers (Score:0)
Depends on whether anything accessible to the container is sensitive.
E.g. password files, password-protected parts of the web root, scripts with embedded secret data or logic, data used by scripts but not downloadable itself, log files, etc.
You'd likely want something more fine grained, like AppArmor or pledge(), that works on paths rather than an entire container or VM.
Re:Containers (Score:2)
My understanding of containers is limited, but I was under the impression that containers can be limited to only allow access to specific directories. So if the application doesn't support whitelists well, or is buggy, then it still can't escape the container.
Re:Containers (Score:0)
My point is you don't want something fine-grained. You want, if at all possible, a whitelist of one directory. URLs pointing to anything outside that directory is considered non-existent. Fine-grained security is leaky security.
Access by directory (tree) is more fine-grained than by entire container! :-)
My understanding of containers is limited, but I was under the impression that containers can be limited to only allow access to specific directories. So if the application doesn't support whitelists well, or is buggy, then it still can't escape the container.
The point is that there are portions of the container that the software inside may need to run but you still don't want exposed.
Imagine that you are using Apache basic access control for part of your web root. The Apache config files and the password file are within (or accessible by) the container, so limiting the bad guy's access to just the container is still harmful.
See previous posts for other examples.
Re:Containers (Score:2)
Access by directory (tree) is more fine-grained than by entire container! :-)
It isn't. It's a full-lock down. It's very easy to audit - how many directories is accessible? One. Which one? That one. Job done. That's very course grained. No ifs, no buts.
so limiting the bad guy's access to just the container is still harmful.
But I'm asking if there are container implementations that can further limit access, not just to the container itself. Is there, like, something you can do with kernel namespaces that limits an application to ever only be able to access one directory specified on startup. Take it away from the server's responsibility entirely.
Re:Containers (Score:0)
Access by directory (tree) is more fine-grained than by entire container! :-)
It isn't. It's a full-lock down. It's very easy to audit - how many directories is accessible? One. Which one? That one. Job done. That's very course grained. No ifs, no buts.
so limiting the bad guy's access to just the container is still harmful.
But I'm asking if there are container implementations that can further limit access, not just to the container itself. Is there, like, something you can do with kernel namespaces that limits an application to ever only be able to access one directory specified on startup. Take it away from the server's responsibility entirely.
You're ignoring the lockdown features mentioned already and saying that you want a "container implementation" to accomplish the same thing. I guess that seems simpler but you're also ignoring explanations of why limiting process access to a single directory either doesn't work or doesn't help.
Let's start a process in a container with only access to one directory, the web root. Oops, exec() just failed because the apache program isn't in that one directory. Neither are the Apache and OS libraries and configuration files under /var/ and /etc/. We could allow read-only access to those paths but you've ruled that out. Where should I put secret password files? Write-only log files? How do I access device files without /dev/?
Re:Containers (Score:2)
Not everything is meant to be taken literally.
Re:Containers (Score:0)
Re:Containers (Score:0)
Protection at jail, container, or VM granularity isn't sufficient if they contain any data you don't want exposed. See https://apache.slashdot.org/co... [slashdot.org] for examples.
They can make attacks on the enclosing system more complex. But without other mechanisms they do not protect data within them if breached.