Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The httplib2 HTTP client library performs unbounded decompression of HTTP response bodies encoded with Content-Encoding: gzip or deflate. A malicious or compromised HTTP server can return a small compressed payload (approximately 150 KB) that expands to an arbitrarily large size in memory (150 MB or more), causing MemoryError or OOM-kill in the client process. This is a classic decompression bomb (zip bomb) attack against the HTTP client. Any application using httplib2.Http().request() against untrusted or attacker-controlled HTTP endpoints is affected. Details Affected code: httplib2/init.py - decompressContent() function The decompression path has two unbounded operations: 1. gzip decompression (line 394): The .read() call with no size argument decompresses the entire gzip payload into a single in-memory bytes object. There is no limit on the decompressed size. 2. deflate decompression (line 397): Similarly, zlib.decompress() returns the fully decompressed content as a…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
httplib2 prior to version 0.10.1, after an initial connection is made, does not verify that the server hostname matches a domain name in the subject's Common Name (CN) or subjectAltName field of the X.509 certificate, which allows man-in-the-middle attackers to spoof SSL servers via an arbitrary valid certificate.
Recommended action: Upgrade to 0.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malicious server which responds with long series of \xa0 characters in the www-authenticate header may cause Denial of Service (CPU burn while parsing header) of the httplib2 client accessing said server. Patches Version 0.19.0 contains new implementation of auth headers parsing, using pyparsing library. https://github.com/httplib2/httplib2/pull/182 Workarounds Technical Details The vulnerable regular expression is https://github.com/httplib2/httplib2/blob/595e248d0958c00e83cb28f136a2a54772772b50/python3/httplib2/init.py#L336-L338 The section before the equals sign contains multiple overlapping groups. Ignoring the optional part containing a comma, we have: \s[^ \t\r\n=]+\s= Since all three infinitely repeating groups accept the non-breaking space character \xa0, a long string of \xa0 causes catastrophic backtracking. The complexity is cubic, so doubling the length of the malicious string of \xa0 makes processing take 8 times as long. Reproduction Steps Run a malicious…
Recommended action: Upgrade to 0.19.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Attacker controlling unescaped part of uri for httplib2.Http.request() could change request headers and body, send additional hidden requests to same server. Impacts software that uses httplib2 with uri constructed by string concatenation, as opposed to proper urllib building with escaping. Patches Problem has been fixed in 0.18.0 Space, CR, LF characters are now quoted before any use. This solution should not impact any valid usage of httplib2 library, that is uri constructed by urllib. Workarounds Create URI with urllib.parse family functions: urlencode, urlunsplit. References https://cwe.mitre.org/data/definitions/93.html https://docs.python.org/3/library/urllib.parse.html Thanks to Recar https://github.com/Ciyfly for finding vulnerability and discrete notification. For more information If you have any questions or comments about this advisory: Open an issue in httplib2 Email current maintainer at 2020-05
Recommended action: Upgrade to 0.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.