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."
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.
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.
OKay.
This bug can only lead to cache poisoning, and not to direct compromise of the servers. It can only be abused if you have a certain kind of setup, namely:
|user|-[internet]-(|proxy|-|webserver|)
That is, on the server side, you have proxy servers in front of the webservers. You'll only need to patch the proxy servers, in such configurations.
The worst that can happen to you (and some will consider this 'pretty damn bad') is that someone replaces your regular index.html with something else residing on the webserver. Could be pretty bad if it's a webboard hidden somewhere on the server with the goatse-pictures.
Anyways, this doesn't effect "single webserver" configurations, only the shops big enough to have a little more advanced configurations.
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
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
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.