HTTP pipelining - indirect security implications

[Amit Klein]

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

[mnot]

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/