The xmlrpc client library is the only stdlib module that has a gzip decompression handler for compressed HTTP streams. The gzip_decode() function decompresses HTTP bodies that are compressed and sent with Accept-Encoding: x-gzip.

A malicious server can send a specially prepared HTTP request that can consume lots of memory. For example 1 GB of \0 bytes is less than 1 MB of gzip data.

Suggestion:
The gzip_decode() should only decode a sane amount of bytes (for example 50 MB) and raise an exception when more data is to be read.

Also see #15955

According to Nadeem it's not (easily) possible to detect how large the output is going to be.

The attached patch adds a limitation to xmlrpclib.gzip_decode().

IMHO the patch should also limit the maximum amount of read bytes in Transport.parse_response(). Do you agree?

I think instead of global variable it will be better to add an optional parameter for gzip_decode() (with a sane default value) and related functions. Or at least in additional to it.

+1 for a keyword argument

I also have to add a limit to GzipDecodedResponse().

Python 2.6 and 3.1 are not affected by the issue. The problematic code was added in 2.7 and 3.2.

CVE-2013-1753 gzip bomb and unbound read DoS vulnerabilities in Python's xmlrpc library

Not blocking 2.7.4 as discussed on mailing list.

blocker for 2.6.9

Ping.  Can we get this fixed before beta 1?

Demoting this from release blocker: apparently, the release-blocking property was only intended for 2.6.9, which has been released.

I'm putting it back to release blocker, because 3.3 should decide whether to fix it/call it security/remove itself from the list.

The patch contains several small changes.  I like the spelling fix (gsip -> gzip) in a test method, but otherwise, I prefer the alternative solution of an additional function parameter with a default.

I would prefer that the marker for "no limit" be None, rather than -1, 0, or anything less than 0.

I also don't see the point of raising a too-much-data ValueError *after* decoding.  While that *might* mean we set the default too low, all we would really know for sure is that there would be a bug in gzip.GzipFile().read -- and ValueError suggests otherwise.

updated patch to use an optional parameter "max_decode".

document the new exception

New changeset d50096708b2d by Benjamin Peterson in branch '2.7':
add a default limit for the amount of data xmlrpclib.gzip_decode will return (closes #16043)
https://hg.python.org/cpython/rev/d50096708b2d

New changeset a0368f81af9a by Benjamin Peterson in branch '3.2':
add a default limit for the amount of data xmlrpclib.gzip_decode will return (closes #16043)
https://hg.python.org/cpython/rev/a0368f81af9a

New changeset 4a9418c6f8ae by Benjamin Peterson in branch '3.3':
merge 3.2 (#16043)
https://hg.python.org/cpython/rev/4a9418c6f8ae

New changeset 6b83e21c8679 by Benjamin Peterson in branch '3.4':
merge 3.3 (#16043)
https://hg.python.org/cpython/rev/6b83e21c8679

New changeset 6f002c4741e2 by Benjamin Peterson in branch 'default':
merge 3.4 (#16043)
https://hg.python.org/cpython/rev/6f002c4741e2