Slashdot Log In
Apache Request Smuggling Vulnerability Found
Posted by
CowboyNeal
on Fri Jul 08, 2005 02:41 AM
from the web-jacking dept.
from the web-jacking dept.
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."
This discussion has been archived.
No new comments can be posted.
Apache Request Smuggling Vulnerability Found
|
Log In/Create an Account
| Top
| 168 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Fix-patch in 5...4...3... (Score:4, Insightful)
(http://www.bannination.com/)
Anyway, it'll get a fix available likety-split. Go, OSS!
Re:Fix-patch in 5...4...3... (Score:4, Informative)
Re:Fix-patch in 5...4...3... (Score:5, Informative)
http://apache.org/docs/misc/FAQ.html#name [archive.org]">http:/
And then said this:
http://www.apache.org/docs/misc/FAQ.html#name [archive.org]">ht
Then they changed it to:
http://httpd.apache.org/docs/misc/FAQ.html#name [archive.org]">
Now they're trying to get rid of something they've perpetuated for years:
http://httpd.apache.org/docs/misc/FAQ.html#name [archive.org]">
and that seems to be the one that's remained until today. Who knows what it'll be tomorrow.
Re:Fix-patch in 5...4...3... (Score:5, Informative)
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.
HTTP request smuggling (Score:5, Funny)
2.1.6 (Score:5, Informative)
(http://webcoderplus.com/blog/ | Last Journal: Tuesday November 02 2004, @08:11AM)
Re:2.1.6 (Score:5, Informative)
Partly, because it's actually a dupe... well disguised, though...
http://it.slashdot.org/article.pl?sid=05/06/12/14
Re:2.1.6 (Score:4, Informative)
(http://www.tlarson.com/)
Webmasters don't need to update anything, because there is no vulnerability from their perspective.
Request smuggling doesn't apply to a single web server, but rather to a combination proxy and web server that use a different method to determine how long a request is. In such an arrangement, an attacker could use smuggling to poison the proxy's cache or what have you, but the only customers who would be affected are others behind the same proxy.
Because this sort of attack is so limited in scope, the chances of any of us ever even hearing about an actual exploit are very slim. The only people who really need to worry are those who run proxy servers.
Only Apache 2.0.x, not 1.3.x (Score:3, Informative)
It's been slashdotted, article text here: (Score:1, Informative)
Wait a sec.. (Score:5, Interesting)
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?
How long will OS X users have to wait? (Score:1)
Where to get fix... (Score:5, Insightful)
Securityfocus article is here [securityfocus.com].
eh? (Score:5, Insightful)
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.
Re:eh? (Score:4, Informative)
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.
Bug was found (Score:5, Funny)
by noticing the apache servers were being forced further and further west
Another Dupe (Score:5, Informative)
(http://insecure.org/)
This seems to be a duplicate of the June 12 article on HTTP Request Smuggling [slashdot.org]. I don't see anything new here, as the original paper [watchfire.com] 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. [insecure.org]
only affects certain setups (Score:5, Informative)
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.
There goes my weekend! (Score:2)
BBH
If you want to be secure... (Score:3, Informative)
(http://www.stevekallestad.com/ | Last Journal: Thursday May 31, @03:02AM)
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.
How is this news? (Score:1)
(http://www.smalldark.net/)
.. so this is an apache vulnerability now. (Score:5, Insightful)
(http://www.midnight-labs.org/)
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.
Apache Vulnerability? (Score:3, Interesting)
(http://inglorion.net/ | Last Journal: Thursday October 06 2005, @07:17AM)
Or am I completely misunderstanding what's going on?
Story & comments are all WRONG (Score:5, Informative)
(http://www.force-elite.com/)
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.
Wow is the slash article wildly inaccurate! (Score:5, Informative)
(http://www.richardharman.com/)
I recently released an internal advisory on this from reading TFA [watchfire.com]. 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.
Important to note that IIS is as bad or worse (Score:3, Informative)
(http://slashdot.org/)
How is it dangerous? (Score:4, Informative)
(Last Journal: Wednesday August 18 2004, @07:52AM)
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 [bank.com] with exploit-redirection to insecure http://bank.com/demo.html [bank.com], 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...
The Cross Site Scripting FAQ (Score:2, Informative)
(http://www.cgisecurity.com/)
www.cgisecurity.com/articles/xss-faq.shtml [cgisecurity.com]
Apache vulnerability? (Score:1, Informative)
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
IIS6 (Score:1)
Vulnerability in Apache PROXY, NOT Apache SERVER (Score:4, Informative)
(Last Journal: Friday July 04 2003, @03:37PM)
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. [slashdot.org] (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.)
HTTP Request Smuggling (Score:2, Informative)
(https://freepository.com/)
- 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.
Re:Damn, now I have to wait for longhorn. (Score:1)
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.
Re:Damn, now I have to wait for longhorn. (Score:5, Funny)
Re:yet another (Score:1, Offtopic)
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
Re:Patch Available (Score:1, Insightful)
Re:Linux folks (Score:1, Informative)
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.
Re:yet another (Score:2)
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.
Re:Damn, now I have to wait for longhorn. (Score:2)