HTTP Request Smuggling

cyphersteve writes "Multiple vendors are vulnerable to a new class of attack named 'HTTP Request Smuggling' that revolves around piggybacking a HTTP request inside of another HTTP request, which could let a remote malicious user conduct cache poisoning, cross-site scripting, session hijacking, as well as bypassing web application firewall protection and other attacks. HTTP Request Smuggling works by taking advantage of the discrepancies in parsing when one or more HTTP devices are between the user and the web server. CERT has ranked this attack and the associated vulnerabilties found in multiple products as High Risk. The authors (Amit Klein, Steve Orrin, Ronen Heled, and Chaim Linhart) have published a whitepaper describing this technique in detail."

Comments

Re:Validation

[Anonymous Coward]

It would mean not only 2 or 3 more packets but another full roundtrip, per transaction. It's also not feasible for the very reason why these attacks work: Intermediate HTTP devices modify the requests (proxies add Client-IP: headers, for example). That would invalidate the checksum.

Re:Validation

[mp3LM]

This shouldn't become a speed problem on broadband machines because it'll only mean 2 or 3 times more packets (but you can always increase packet size).

Are you serious?!?!? This could kill an already decently loaded web-server.
If it's twice as many packets, that's doubling the workload!

Also, I think you mis-read the issue. The issue isn't someone hijacking someone elses HTTP request, it's someone who wants to attack a server by sending a request inside there own request, in which case the checksum would still pass.

Question of Compatibility vs. Reliability

[l2718]

This exploit is interesting, and is related to a cultural issue: how do you handle malformed input?

There are two basic approached to this: either you reject it (the sound, security-concious way), or you attempt to make sense of it (the compatible way). The second solution allows your software to interface with badly-written external code, at the cost of interfacing with intentionally malformed requests like the exploit the describe.

The reason the exploit works is that different people have different methods for determining what the sender of the malformed packet really meant, and if two different interpretations are applied to the same packet you can use the resulting "confusion" to your advantage. Different recount results which depend on guessing "voter intent" from malformed ballots in Florida comes to mind.

Re:Question of Compatibility vs. Reliability

[iabervon]

The actual issue is cases where someone makes sense of malformed input and then passes that input on to something else. The proper thing to do is always pass on correctly-formed input. If you get malformed input and interpret it somehow, you then need to pass on your interpretation, not the original. The guideline is to be permissive in what you accept and strict in what you transmit; when you're passing something on, you need to canonicalize it in transit.

A good example of this is how the legal system works. When a court makes a decision on the application of a law to an unclear situation, that becomes part of the case law, such that there is a consistent interpretation, rather than an ambiguous situation being interpreted randomly each time it occurs.

publicfile

[sugarmotor]

http://cr.yp.to/publicfile.html, publicfiloe, is not mentioned.

Well this is not good

[suitepotato]

From TFA:

Conclusion: We have seen that there are many pairs (proxy/firewall servers and web servers) of vulnerable systems. Particularly, we demonstrated that the following pairs are vulnerable: PCCA o IIS/5.0 o Tomcat 5.0.19 (probably with Tomcat 4.1.x as well) Squid 2.5stable4 (Unix) and Squid 2.5stable5 for NT o IIS/5.0 o WebLogic 8.1 SP1 Apache 2.0.45 o IIS/5.0 o IS/6.0 o Apache 1.3.29 o Apache 2.0.45 o WebSphere 5.1 and 5.0 o WebLogic 8.1 SP1 o Oracle9iAS web server 9.0.2 o SunONE web server 6.1 SP4 ISA/2000 o IIS/5.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 DeleGate 8.9.2 o IIS/6.0 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 Oracle9iAS cache server 9.0.2 o WebLogic 8.1 SP1 SunONE proxy server 3.6 SP4 o Tomcat 5.0.19 o Tomcat 4.1.24 o SunONE web server 6.1 SP4 FW-1 Web Intelligence kernel 55W beta (the IIS 48K technique probably works with R55W) o IIS/5.0 This is a partial list - there are many pairs we did not test and there are likely many other web servers and cache servers we did not test for lack of hardware and software. Of course, there are probably many more similar techniques.

Yeah, really? I'd like to see a much broader list laid out, and preferably before it becomes another net disaster.

If this was strictly a Microsoft thing we'd be hearing cries for blood, or at least an app to check if your setup was vulnerable. Since it is much broader than that, if checking for this doesn't become part of a security toolkit, we may well wish it had.

Oh well. At least we got this much warning this much in advance. Anyone want to take bets on how long till some malware weasels make this a point and click thing in another script kiddie kit? My guess is before the security world makes a test app to check for it.

Re:Hype it up?

[Sven Tuerpe]

Why not just issue seperate advisories and inform the respective vendors? Seems to me like they bundled multiple flaws in multiple products so they could be creditied with discovering a new class of vulnerability.

Because the whole point of this type of vulnerability is undesired interaction between different implementations of the same protocol. No single product will ever be vulnerable and each and every vendor might well point to the next one saying it's their fault.

Re:That's already what Apache does

[AndroidCat]

A HTTP request is supposed to end with a CR/LF. If that's not what's at the end of the Content-Length, perhaps the request should be dumped? (I'm too lazy to check the RFCs to see how binding that requirement should be.)

Re:Validation

[Lord Kano]

Anyone capable of pulling off a man in the middle attack could intercept the MD5 sum. Send the user a false one, return a valid MD5 to the server and go on as usual.

LK

Re:Quick Summary

[MooseGuy529]

Due to bad handling of borderline html

You mean HTTP, right?

Re:Why is this news?

[segmond]

Shut up! RTFP!

The attack allows attack worse than XSS if an XSS vulnerability exists since this time, it doesn't require you to intereact with the client. It allows cache poisoning. It allows you to smuggle data past some firewall/filters that try to prevent HTTP attacks by parsing requests, for example, so servers will filter out GET requests like /foo/../../../whatever or /foo?cmd.exe You can use this to bypass it. This is NEWS because it is a NEW attack. This is not about using HTTP as a tunnel for other form of communication.
This exploits the fact that the cache server/firewall and webserver might parse the same request different when it has two "Content Length:" in it... Read the paper.