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."
After all, it is Apache server.
Anyway, it'll get a fix available likety-split. Go, OSS!
"A great democracy must be progressive or it will soon cease to be a great democracy." --Theodore Roosevelt
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
at least 1.3.x is safe from this, I'll sleep well tonight.
"Don't let fools fool you. They are the clever ones."
Extract: All versions of Apache previous to 2.1.6 are vulnerable to a HTTP request smuggling attack which can allow malicious piggybacking of false HTTP requests hidden within valid content. This method of HTTP Request Smuggling was first discussed by Watchfire some time ago. The issue has been addressed by an update to version 2.1.6. Editorial Comment: The vulnerability involves a crafted request with a 'Transfer-Encoding: chunked' header and a 'Content-Length' can cause Apache to forward a modified request with the original 'Content-Length' header. The malicious request may then piggyback with the valid HTTP request possibly resulting in cache poisoning, cross-site scripting, session hijacking and other various kinds of attack. This vulnerability has resurfaced due to vendor confirmation, the original Watchfire Whitepaper on HTTP Request Smuggling is here. addict3d reports that mostly all Apache 2.0.x versions, on the major platforms, are vulnerable to this attack. Apache has promptly released a 2.1.6 version of their HTTP software to address this issue.
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?
until Apple releases an update. Probably a month .... sigh.
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.
Why is this slashdot material?
/AC
It is old news, and if someone has an interest in security they should subscribe to the relevant lists.
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.
Anyone else gonna be working all weekend due to this? Bout 300 non-homogenous servers with non-stock versions of apache on 3 or 4 different platforms should take the better part of two working days. I guess it beats the alternative.
BBH
If you want to be secure, either downgrade to apache 1.3 or take a chance on the alpha version of 2.1.
This is the second major problem in the last several weeks that leaves all the "managed server" users out there very vulnerable. (The first being the XML-RPC problem with php) Most of the managed servers out there run Apache off of an RPM compatible with their manager of choice (Plesk, cPanel, etc.). And a lot of the companies out there will make you pay extra to update your server or even wait until RH or Plesk distributes a new RPM.
I think it's going to become apparent to a lot of people very quickly that it's worth the money to pay for a managed server from a quality company that provides real support rather than the $99/month for a server and a gig of bandwidth shops that will leave your servers wide open to these vulnerabilities.
This has been discussed before, there was a whitepaper posted on Slashdot previously. As others have said, the patches for this are already in 2.1.6 and just need to be backported to 2.0.x. 2.0.55 has been in testing, I believe the patches are there. So one could grab the code and backport them yourself, or wait for 2.0.55 to be released, which I would expect would be very soon.
Am I the only one picturing Bill Gates walking around saying "I am a chicken hawk!" ???
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.
Following this thought line, they could as well rename it Windows Heisenberg. Uncertainty Server would do, also.
Yes, I know, off topic. Sorry, couldn't resist.
My other post is a First.
I don't know anything about this post, but how is it redundant as the fourth post when the first 3 were:
1) Yeah!
2) not good not good
3) After all, it is Apache server. Anyway, it'll get a fix available likety-split. Go, OSS!
Now I could see if this post said yeah, or good or server in the post but I'm just not getting the redundant mod anymore.
~S
But then Time Warner AOL Netscape etc. Inc. will sue Microsoft for patent infringment under the justification that using Foghorn for a windows product has completely damaged the reputation of their imaginary character, causing microsoft to go out of business.
Once Microsoft goes out of business, the current AOL will fail because they were never able to switch from IE->Netscape (despite the fact they BOUGHT Netscape).
Netscape will also fail (to install) preventing AOL from making the switch, dragging Time Warner down with them. The stock price will drop so low, that Steve Jobs will buy Time Warner, resurrect AOL, and instantly stop innovating because he no longer has competition and controls the internet connection of millions that he can direct to iTunes.com.
Hey...it could happen! hehe
To me it seems that this is mostly an attack on proxying servers, causing them to misbehave and send malicious requests to Apache (a bit similar to the old FTP PORT exploit). Then how is this a vulnerability in Apache, if it's the proxy that compromised, and Apache just handling what it thinks is a legitimate request?
Or am I completely misunderstanding what's going on?
Please correct me if I got my facts wrong.
I'm kind of in the neutral OS camp, I use Microsoft stuff a lot, develop with .Net, but I like Linux and think it's a great OS. However the linux fan boys irritate me - if this article was about an exploit in IIS, you guys would be frothing at the bit trying to think of snide comments.
All I've read from these replies are how quickly it was fixed (which is a great feaure of OSS I readily admit) and how insignificant the exploit was. One guy's reply was that this won't affect 90% of the apache boxes out there - 10% of the apache boxes is a lot of boxes! Anyway, let the snide comments begin...
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.
?
I think you misspelled "Hindenberg."
After all, I am strangely colored.
Damn you! I just tried that patch and now my security has plummeted!! Especially as I had to install Windows to get it to run!
Time is an illusion. Lunchtime doubly so. - Douglas Adams
Stability and Security, boyee.
No, I really meant Heisenberg.
Nonetheless, Hindenburg will also be appropriate when the time is come.My other post is a First.
Based on the original and detailed exploit report. No news on a patch for that, I notice.
If you were blocking sigs, you wouldn't have to read this.
I used to run Red Hat Linux then Fedora. Red Hat moved to Apache 2.0. I prefer Apache 1.3 as it suits my needs just fine and still seemed to be in a state of flux. Running RH/Fedora with older versions of programs like Apache is a real pain in the ass, due to all the dependencies, especially if you want to keep up to date with the latest fixes.
With Gentoo I get the choice and unlike Red Hat or Debian who back port patches to older versions, with Gentoo you get the latest fix from the vendor.
Well, not very dangerous. :)
To affect someone directly, the client browser would have to be compromised to send doctored HTTP requests. If this happens to you, you're already 0wn0red, this little trick might at worst add insult to injury
But imagine this: luser.isp.net connects daily to bank.com through proxy.isp.net
evil.isp.net has tapped into the same LAN as Luser. evil.isp.net sends a doctored request to secure http://bank.com/login.php with exploit-redirection to insecure http://bank.com/demo.html, through proxy.isp.net
From now on, proxy.isp.net will serve demo.html to anyone who wants to access login.php. So luser happily types his real password and login into demo submit form (not looking at the lock icon) and happily clicks "submit", while evil.isp.net just sniffs the LAN and captures unencrypted POST request containing real password and login.
That's about as far as it goes. You can't do much if bank.com has DEMO with wide letters across the demo page. You can't redirect to offsite pages, and generally your possiblities are low...
Anagram("United States of America") == "Dine out, taste a Mac, fries"
www.cgisecurity.com/articles/xss-faq.shtml
Believe me, if I started murdering people, there would be none of you left.
Put that in your pipe and smoke it, M$ fanboys.
It's open source and the Apple compiler is GCC. Just recompile the fixed version from source.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
As always the editors at slashdot are right on the money with the facts and the headlines.
It's an HTTP vulnerability, not Apache specifically, genius... It can affect any user connecting to any web server that has some sort of cache device between them and the web server.
Before sensationalizing another "apache vulnerability" and giving the uninformed microsoft stiffs another thing to talk about at happy hour... READ THE FREAKING FACTS and COMPREHEND WHAT YOU READ. If you don't know the subject matter, let someone else come up with the story and post it.
GEEZ
l8,
AC
Maybe, maybe not.
It'll get fixed soon enough.
It's better then what you have to deal with if your using Microsoft products.
When is MS going to come out with it's own set of patches to fix it's own "HTTP Request Smuggling Vulnerability" with IIS 5 and 6?
At least with Apache you know there is a fix coming, with Microsoft I bet there is a 50-50 chance that they will simply not acknowledge it as a real problem!
Save your selves! I am upgrading to IIS6!
Isn't this what slashbot does when a Microsoft vulnerability comes out?
Hmm... Seems to me like you want to hide problems in the open source community, rather than be open and transparent about it.
Actually, the blurb mis-cites the affected versions. 1.3.x is affected as well.
However, this is hardly a problem for anyone. It only affects users of mod_proxy, and then it only allows another request to the backend, which is to say your backend would need to have some other vulnerability in it to do anything useful.
*I shamelessly stole this analysis from chipig on #gentoo-apache, who's an apache herd member.
Given a choice between free speech and free beer, most people will take the beer.
And I thought it was called "Longinthetooth" these days. Or maybe "Microsoft Windows Forever."
Given a choice between free speech and free beer, most people will take the beer.
All versions of Apache previous to 2.1.6 are vulnerable to a HTTP request.
Why the hell do you have 300 non-stock versions of apache on 3 or 4 different platforms? Apache is apache on whatever platform, pick one and use it. And apache supports modules you know, you don't need to compile a custom apache all the time, it just makes life difficult for no reason.
Yet another dupe but whats worse is it seems to be another platform being used by "Whitedust" to media whore and put their name out there. Just take a look at this ridiculous press release.
I distinctly recall going to the Apache web site right after it was announced. They explained the "a patchy server" thing there. They explained it on the NCSA httpd mailing list. They said it everywhere; they were quite up front about it. I distinctly recall as I thought it was moderately clever, but not really very cute. But I still liked the name, and eventually converted to Apache when NCSA gave up on their httpd. (I was maintaining a couple of ports.)
I don't know if a spin doctor is in charge, or someone thinks it sounds juvenile, and thinks that part of growing up and leaving college behind is to lie and cover your tracks (OK, maybe they've been hanging around national level politicians).
Whatever the explanation, I would happily testify in a court of law that this is what they said from the beginning.
Sorry; my fingers got carried away. Maybe it's the Apache influence. 8^)
I was helping maintain a couple of ports, doing tests and submitting patches. I wasn't a primary maintainer. Just to keep things straight!
It would appear that it *was* a bug in 1.3 (it's not very clear on most of the pages). And it seems to have been fixed in 1.3.33, as you can read here:
l
http://www.apache.org/dist/httpd/Announcement.htm
isn't it funny that when someone questions the accuracy of a slashdot article regarding MS, they are labelled as a troll and their account is imediately banned from posting comments for a period of 1 month. If someone question a Slashdot article regarding an Open Source piece of software thety are modded up. Perhaps one can read into that, that Slashdot readers do not want to hear the real truth about things? Seems pretty clear to me after looking at the history of many slashdot account holder. Not so funny anymore. I choose not to allow myself to be coerced into believing nonsense promoted by obviously twisted methods.
There has been a LOT of confusion among posts here. Let me spell it out:
1. This vulnerability is in the Apache web proxy version 2.x.
2. This vulnerability does NOT affect the Apache web server, unless an Apache web proxy is running infront of it.
3. The vulnerability is discussed on page 12 of the whitepaper. The rest of the whitepaper is about other similar vulnerabilities in other software.
I read the whitepaper in detail because I have written an HTTP server and wanted to know if I am vulnerable to this attack. The paper actually describes a very large number of attacks, most of which have to do with bugs in old web servers and proxies (not even Apache). Most of the people I see posting here, including those who claim they read the article, are clueless, as they did not read through the whole paper to find the one page related to Apache.
Well, it turns out that this bug is NOT in the Apache server. It is in the Apache web proxy. So, if you use an Apache web proxy infront of your server (regardless of what actual server software you use), you are vulnerable. Also, if you have clients who use an Apache proxy on their end, they are vulnerable. Server administrators should only worry about the former case, obviously.
Yes, a lot of people run caching proxies infront of their own web server, such that every single request to the server -- from all clients -- goes through the proxy. This is often done for performance with dynamically-generated web sites. If you have not heard of this type of setup, then you clearly don't have one, and you can ignore this vulnerability.
The following claims, made in other posts, are FALSE:
- "It's an HTTP vulnerability, not Apache specifically" (Wrong. The Apache proxy clearly mis-handles requests with a Transfer-Encoding header.)
- "To affect someone directly, the client browser would have to be compromised to send doctored HTTP requests." (Wrong. The paper is about using malformed requests to damage a server. The client would send such requests intentionally, in order to cause such damage.)
- This entire post. (The guy only read the first vulnerability described in the paper, not the Apache-specific one.)
- "Sure, this effects Apache, but this also effects just about all web servers where the request is first filtered through a cache or proxy..." (No, only ones filtered through an Apache proxy.)
- HTTPS is not affected
The white paper, while seemingly complete and well written, mentions this almost in passing near the end of the document. That may cause many readers, if they simply skim the paper, to miss this critical point. Further, it discounts using HTTPS as "...an impractical solution".
If security is engineered into your site from the beginning, there's nothing at all impractical about using HTTPS.
(Even that's not totally accurate, because it wasn't called "America" then.)
I was born in New Jersey, which makes me 100% "Native American", even though only some of my ancestors were here before Columbus came.
Calling someone "Native American" is as silly as calling someone "African American" (because all Americans (even Persons of Pre-Columbian American Immigrant Ancestry) are "African Americans", if you go back far enough).
OTOH, people called the Apaches "Indians" (or "American Indians") for the longest time, and I (being part "American Indian") don't see the harm in continuing to use that term (since it wasn't meant in a deragotory way, unlike the way that "the 'N' word" was (and still is) used to describe People of Recent Sub-Saharan African Ancestry), although I think that, in most cases, people shouldn't be classified by race or ancestry in the first place.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Should be "derogatory".
Sorry.
Why the hell do you have 300 non-stock versions of apache on 3 or 4 different platforms?
Mainly because Cingular Blue(attws), Cingular Orange, Nextel, Boost, Dobson, Triton, Tais Toshiba, and Alltel all have different backends. There is some consolidation (70 Cingular boxes are identical, 50 nextel boxes are identical, etc) but overall, I'm looking at about 10-15 different installations and a handful of custom modules that are not ABI compatible from version to version. On a scale of one to clusterfuck, I'd say it's about a 4 (basically, it's a lot of work and I need to have my shit together on a daily basis).
I appreciate your concern/surprise, but not all telcom network operators' backends are rosy and neat.
BBH
Custom modules that are not ABI compatible from version to version? Versions of what? All apache 2 modules work on all minor versions of apache 2, same for apache 1 with apache 1 modules. So I don't know what you are talking about there.
All you need to do is recompile your httpd binary for each OS that doesn't provide apache binaries, and push it out to each server running that OS. Its really not that big a deal, unless you do every machine by hand or something. If you spend a whole weekend on this, then you should spend some time learning how to automate simple tasks.