Bugs item #2928620, was opened at 2010-01-09 02:06
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2928620&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: wrong behaviour
>Status: Closed
>Resolution: Fixed
Priority: 7
>Private: No
Submitted By: Wesley Miaw (josuah)
Assigned to: Daniel Stenberg (bagder)
Summary: content_encoding may send > CURL_MAX_WRITE_SIZE bytes

Initial Comment:
The contract libcurl provides to the user-provided write callback is that the data (size * nmemb) will not exceed CURL_MAX_WRITE_SIZE bytes. However if the content goes through the content_encoding.c inflate_stream() method, zlib is given a working buffer of 64K (DSIZ = 0x10000). In some cases, the inflated data will exceed CURL_MAX_WRITE_SIZE which violates the write callback contract.

For some implementations this may cause a crash as the code may have only allocated a buffer of CURL_MAX_WRITE_SIZE or assumes size * nmemb to be <= CURL_MAX_WRITE_SIZE.

This can be fixed by changing DSIZ in content_encoding.c equal to CURL_MAX_WRITE_SIZE:

#define DSIZ CURL_MAX_WRITE_SIZE

I have confirmed this size mismatch exists in content_encoding.c of 7.19.7.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-02-11 12:07

Message:
Thanks for the report, this problem is now fixed in CVS!

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-01-09 13:54

Message:
BTW, I didn't mention this but I selected to make this report "private" due
to the possible security implications. I want to investigate the effects
properly before I un-private this again.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-01-09 13:49

Message:
Eeeek. thanks for this report. I'm just curious, how come this doesn't hit
anyone in the face much more obvious and often than it apparently does? I
mean this code has been like this for a long time and so far you're the
first to report this and if I read the code right this could lead to a heap
buffer overflow. Any idea what I can do to _force_ this problem to happen?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=2928620&group_id=976
Received on 2010-02-11