[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: APT do not work with Squid as a proxy because of pipelining default



Robert Collins <robertc@robertcollins.net> writes:

> Well, I don't know why something has 'suddenly' become a problem: its
> a known issue for years. The HTTP smuggling
> [http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf]
> attacks made that very obvious 5 years ago now.

Reading that I don't think that is really a pipelining issue. You do not
need pipelineing for it to work. The real problem is keep-alive. The
connection isn't destroyed after each request so you can put multiple
requests into the stream and exploit different brokenness in different
parsers along the way.

Take the first example from the pdf
[http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf for non-stale
link]:

You send the first request to the proxy which it passes along:

POST http://SITE/foobar.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
Connection-Type: application/x-www-from-urlencoded
Content-Length: 0
Content-Length: 44
[CRLF]
GET /poison.html HTTP/1.1
Host: SITE
Bla: [space after the "Bla:", but no CRLF]

As the paper says the SunONE Proxy uses the second Content-Length entry
while SunONE W/S uses the first. So server replies with foobar.html and
after it is done it starts reading the second request starting at GET
and stalls because the request is incomplete.

Then you send the second request to the proxy:

GET http://SITE/page_to_poison.html HTTP/1.1
Host: SITE
Connection: Keep-Alive
[CRLF]

And the server responds with poison.html while the proxy caches that
under page_to_poison.html.


Note that I did not pipeline the requests to the proxy. And still I
managed to poison it. I also didn't need the server to pipeline
responces, only to not fail if multiple requests are send without
waiting for the first to complete. Something that is required for
HTTP/1.1 conformance. Pipelining just makes more of those attacks
possible, those where the first parser sees multiple requests while the
second sees only one.

> http://en.wikipedia.org/wiki/HTTP_pipelining has a decent overview.

That nicely shows how much better pipelining is for the performance.

> Its nice an interesting that some recent software has it on, but that
> is generally because the authors don't realise how broken it is,
> IMNSHO :).
>
> -Rob

I think you have failed to show that pipelining is broken. What seems
"broken" is Keep-Alive. Do you suggest we stop using Keep-Alive to
prevent broken parsers from being exploited? Make a full 3-way handshake
for every request?

MfG
        Goswin


Reply to: