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."
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.
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.
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.
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.
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.
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.
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.
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.