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."
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."
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.
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?
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.
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.
A problem with one Apache thread will crash the entire server.
That's only true on Windows, where for performace reasons all requests are served by one process - which is automatically restarted by a second moitoring process if it crashes.
On Unix, by default it uses the "prefork" MPM - multiple threads, single thread per process, just like 1.3. There are various multithreaded MPMs such as "worker", but you have to enable them manually
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"
You're right in that request smuggling requires two entities. In this particular case, the two entities are:
1. Apache
2. An HTTP proxy, HTTP caching proxy, or HTTP-aware firewall
The reason the security flaw affects one product (Apache), is because the flaw does not require abnormal operation from the proxy, cache, or firewall.
www.cgisecurity.com/articles/xss-faq.shtml
Believe me, if I started murdering people, there would be none of you left.
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
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.