On Wed, 23 Sep 2009, johansen_at_sun.com wrote:

> Perhaps I have misunderstood, but based upon your description, doesn't this
> limit what the HEADERFUNCTION can do to defend against such an attack?

Yes. That would be an attack that libcurl itself needs counter-measures for,
as the app won't be the one that can decide when to stop.

libcurl does the service of putting each complete header in a buffer before it
calls the app simply to make life easier for the apps, since they can thus
assume that they always get full headers and not have to support getting tiny
fragments or pieces with embedded newlines etc.

> If the remote host sends libcurl an arbitrarily long string and the library
> allocates space to hold it, then the client will have allocated a large
> amount of memory before the HEADERFUNCTION has a chance to return a write
> error and abort the transaction. Is the idea that if the HEADERFUNCTION
> returns a write error, then we'll free the header buffer before we get into
> too much trouble?

It's simply so that libcurl hasn't been done to safe-guard against an "attack"
of this kind. Responding with a HTTP stream that sends an "infinite" length
HTTP header will cause libcurl to attempt to allocate a buffer for that header
and thus it will realloc() away until it gets no further memory.

lib/transfer.c:readwrite_http_headers() is the responsible function. I guess
at least some kind of fixed maximum header length (like a 100KB or 1MB or so)
is suitable to use there. Wouldn't you agree on that?

-- 
  / daniel.haxx.se
_______________________________________________
http://cool.haxx.se/cgi-bin/mailman/listinfo/curl-and-python