Re: HTTP pipelining - indirect security implications

Thanks, Amit.

Do you think you could take a stab at a proposal for text that would  
be appropriate to put in Security Considerations? It doesn't have to  
be conclusive, just highlight the risks to implementers.

Sections 5 and 6 of <http://tools.ietf.org/html/rfc3552> may be  
useful, if you're willing to take this on.

Cheers,


On 02/04/2009, at 7:45 PM, Amit Klein wrote:

> Hi
>
> I want to draw your attention to an application (not HTTP-level)
> vulnerability whose impact can be amplified by HTTP pipelining. In
> other words, starting to support HTTP pipelining (which is not an
> issue in itself!) in earnest may result in increasing the attack
> surface of an application level vulnerability.
>
> About five years ago, I published a paper describing the "HTTP
> Response Splitting" attack
> (http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf 
> ).
> At that time, HTTP pipelining support was practically non-existent.
> Clients (browsers) didn't pipeline by default, and proxy servers
> "de-pipelined" incoming requests, so that if several requests were
> sent by their client, they would send a single request to the upstream
> server, receive its request, send it to the client and only then
> process the next (queued) request.
>
> This behavior made it harder to really exploit the HTTP Response
> Splitting vulnerability: the server did send out two responses, but
> the proxy (or the client) could:
> - Ignore the excess data (bad for the attacker - needs to carefully
> time the attack so that the second request arrives before the second
> response from the server)
> - Ignore part of the excess data (e.g. up to the buffer end, or the
> packet end) - bad for the attacker since the attacker needs to study
> the systems and understand what are the buffer/packet limits.
> - Queue the excess data (that was ideal from the attacker's
> perspective, yet in the wild, it was not a very popular architecture).
>
> I believe pipelining changes all that - proxy servers (and clients at
> large) will probably opt for queuing excess data, which would make
> HTTP Response Splitting attack much more effective.
>
> Again - this isn't a problem with pipelining in itself. The problem is
> at the application level (allowing the HTTP Response Splitting
> condition), but there are many vulnerable applications out there, and
> "suddenly" pushing HTTP pipelining may adversely affect them. And I
> know HTTP pipelining is not new, it is part of RFC 2616, but perhaps
> this is the place to make notes about possible security implications.
>
> Thanks,
> -Amit
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 8 April 2009 06:33:55 UTC