Slashdot Mirror
Apache Request Smuggling Vulnerability Found
An anonymous reader writes "Whitedust is reporting on a HTTP request smuggling vulnerability in Apache. The flaw apparently allows attackers to piggy back valid HTTP requests over the 'Content-Length:' header, which can result in cache poisoning, cross-site scripting, session hijacking and other various kinds of attack. This flaw affects most of the 2.0.x branch of Apache's HTTPD server."
Damn pirates! They're everywhere.
Caesar si viveret, ad remum dareris.
2.1.6 has been released to fix this. This was responded to quickly, so now its just up to the web masters to update their servers.
East Coast Brewers
1.3.x is very stable and production ready
2.0.x is very stable and production ready, but it doesn't have the same amount of years on its neck as 1.3.x - and thus doesn't have as widespread deployment.
2.1.x is alpha-quality, and it has the fix..
messed up priorities?
According to securityfocus, this bug does affect the 2.0.x branch as well as 2.1.x. It says that the 2.1.x version has been released to fix, and that a fix is available in the subversion repository for 2.0.x. I'd suspect that there will be a new version of 2.0.x out soon.
Securityfocus article is here.
How can request smuggling affect ONE product? I thought the attack was based on the different ways TWO or MORE different products interpret the same HTTP request.
Example:
Product A (web server) uses the FIRST content-length header.
Product B (application server) uses the LAST content-length header.
So you include two content-length headers, to slip by A and attack B.
Replace A and B with whatever proxying whatever setup you can think up.
So how does Apache by itself have this problem, and how can apache by itself SOLVE the problem?
Btw, this is a great example of why "be liberal in what you accept" is BS. You should reject all out-of-spec data.
by noticing the apache servers were being forced further and further west
There is truth in humor.
This seems to be a duplicate of the June 12 article on HTTP Request Smuggling. I don't see anything new here, as the original paper also talks about Apache being susceptible to this relatively minor (yet still interesting) issue.
-Fyodor
Concerned about your network security? Try the free Nmap Security Scanner.
Looking at their whitepaper. This seems to only affect a caching service or proxy.
The attack basically makes the cache think you're requesting one page, but it passes a different request to Apache.
So unless you have some service between your web server and the public, this vulnerability doesn't seem to affect you.
To wit: you ask the cache for Page A with a GET for Page B buried in the header. The cache finds that Page A has expired, and passes your request to Apache. Apache instead serves up Page B, the Cache then sticks Page B's data into Page A's cache.
Sure, this effects Apache, but this also effects just about all web servers where the request is first filtered through a cache or proxy...
What we don't need is people running around like headless chickens screaming 'omg dat aprache server got r00ted.. wher3s the sploit!' as 90% of Apache servers on the internet will be completely uneffected by it.
It seems the poster didn't read the (very intresting) Watchfire paper before submitting. And editors... do your job, otherwise you'll soon be replaced by monkeys trained to click the 'Accept Article' button all day.
First, 1.3, 2.0. and 2.1 were all vulnerable to some parts of this security issue.
Second, it is not a major security issue for most users.
It can only be useful if you are running mod_proxy. And even then, it just allows unfiltered requests to the backend. Most people don't even use mod_proxy. If you do, this could have bad implications, but someone still needs to eploit your backend server. It doesn't give anyone a shell or anything like that.
2.1.6-alpha was released with a fix. 2.0.55 should be coming out very shortly.
No, you're not pigging back data over the Content-Length: HTTP/1.1 header, you're abusing the HTTP/1.1 header to confuse a required combination of a proxying firewall (or proxy/cache) and a webserver.
I recently released an internal advisory on this from reading TFA. Folks, the sky is not falling. 99% of consumers out there will not be affected. People behind NATing firewalls will not have issue. People behind proxies (Squid to name one), and proxying firewalls (Checkpoint, Symantec, etc) will be the ones "vulnerable" to this "attack".
The deal is this:
Proxy A uses Content-Length: header #1, and Webserver A uses Content-Length: header #1 == no problem, no vulnerability.
Proxy A uses Content-Length: header #1, and Webserver B uses Content-Length: header #2 == problem.
That is how it's done. TFA says this may be used to bypass intrusion detection systems. Sure, if you don't have defence in depth. Otherwise you're fine.
da w00t. mtfnpy?
There's a well known thought experiment called Schrodinger's Server. You put a Windows Server in a box along with a test tube full of poison capped by a single atom. You then seal the box. According to the Windows Heisenberg Uncertainty Server Principal, at any point in time the server in the box is simultaneously dead and dead.
If you don't want crime to pay, let the government run it.
Er, did you even read the link you provided? It's a myth that Apache was named because it's "a patchy server". It was named because of the Apache people's meritocracy.
It's a myth that it's a myth that Apache was named that. From their website, the FAQ originally said this:/ web.archive.org/web/19980128114236/http://apache.o rg/docs/misc/FAQ.html#name t p://web.archive.org/web/20000815061003/http://www. apache.org/docs/misc/FAQ.html#name h ttp://web.archive.org/web/20021017033945/http://ht tpd.apache.org/docs/misc/FAQ.html#name h ttp://web.archive.org/web/20030603200610/http://ht tpd.apache.org/docs/misc/FAQ.html#name
http://apache.org/docs/misc/FAQ.html#name">http:/
And then said this:
http://www.apache.org/docs/misc/FAQ.html#name">ht
Then they changed it to:
http://httpd.apache.org/docs/misc/FAQ.html#name">
Now they're trying to get rid of something they've perpetuated for years:
http://httpd.apache.org/docs/misc/FAQ.html#name">
and that seems to be the one that's remained until today. Who knows what it'll be tomorrow.
The bottom line is, according to archive.org, apache themselves claimed the "a patchy server" explanation on their own FAQ page from 1997 through Oct 2002.
Somewhere in there, they started tacking on an extra paragraph saying that to some developers, it also connoted the Indian meaning.
Somewhere between Oct 2003 and Feb 2003, they started calling the "a patchy server" explanation a myth, and saying the real explanation was the Indian thing.
Those of us who were around back when people used to run things like CERN httpd and NCSA httpd remember well that Apache was originally just a set of patches to fix/improve NCSA httpd, before it finally branched off into it's own seperate product. The "patch server" explanation fits the facts of the matter best.
11*43+456^2