It was found that original patch for issues CVE-2015-1283 and CVE-2015-2716 used overflow checks that could be optimized out by some compilers applying certain optimization settings, which can cause the vulnerability to remain even after applying the patch.

One pattern in the fix for CVE-2015-1283/CVE-2015-2716 is:

/ bufferSize is positive here / do { bufferSize = 2; } while (bufferSize < neededSize && bufferSize > 0); if (bufferSize <= 0) { errorCode = XMLERRORNOMEMORY; return NULL;

Any of the modern optimizing compiler, IF able to infer that bufferSize is initially positive (which is true but not obvious to see through local reasoning), will eliminate bufferSize > 0 as always true when the execution is defined, and bufferSize <= 0 as always false when the execution is defined.

Without knowing that bufferSize starts positive, an optimizing compiler could also move the test bufferSize > 0 out of the loop, that is, compile the code as if it had been written:

if (bufferSize <= 0) errorCode = XMLERRORNOMEMORY; return NULL; else { do { bufferSize = 2; } while (bufferSize < neededSize); }

Both cases leads to not eliminating the vulnerability.

Upstream patch:

https://sourceforge.net/p/expat/codegit/ci/f0bec73b018caa07d3e75ec8dd967f3785d71bde/tree/expat/lib/xmlparse.c?diff=a238d7ea7a715ef3850c4cbdd86aeda7077b6bbc

The gzipdecode function in the xmlrpc client library in Python 3.4 and earlier allows remote attackers to cause a denial of service (memory consumption) via a crafted HTTP request.

The CGIHTTPServer module in Python 2.7.5 and 3.3.4 does not properly handle URLs in which URL encoding is used for path separators, which allows remote attackers to read script source code or conduct directory traversal attacks and execute unintended code via a crafted character sequence, as demonstrated by a %2f separator.

Race condition in the getmaskedmode function in Lib/os.py in Python 3.2 through 3.5, when existok is set to true and multiple threads are used, might allow local users to bypass intended file permissions by leveraging a separate application vulnerability before the umask has been set to the expected value.

Dominic Scheirlinck of VendHQ reports:

Many software projects and vendors have implemented support for the “Proxy” request header in their respective CGI implementations and languages by creating the “HTTPPROXY” environmental variable based on the header value. When this variable is used (in many cases automatically by various HTTP client libraries) any outgoing requests generated in turn from the attackers original request can be redirected to an attacker controlled proxy. This allows attackers to view potentially sensitive information, reply with malformed data, or to hold connections open causing a potential denial of service.

An integer overflow during the parsing of XML using the Expat library.

A vulnerability in Python's http, ftp and url libraries was reported, allowing to inject additional HTTP headers and more.

Upstream bug: https://bugs.python.org/issue22928

Upstream patches Python 3.4 / 3.5 : revision 94952 : https://hg.python.org/cpython/rev/bf3e1c9b80e9 Python 2.7 : revision 94951 : https://hg.python.org/cpython/rev/1c45047c5102

Additional note : When used in combination with flaw described in BZ 1347549, an attacker could direct an HTTP connection to a malicious server, using the following combined issues:

Python's httplib does not validate HTTP header values. A malicious 'Host' header with quoted new lines can inject additional headers and more glibc's getaddrinfo() ignores new lines and everything after a new line character when the first part looks like a IPv4 address

See the following blog post for additional information: http://blog.blindspotsecurity.com/2016/06/advisory-http-header-injection-in.html

Integer overflow in the getdata function in zipimport.c in CPython (aka Python) before 2.7.12, 3.x before 3.4.5, and 3.5.x before 3.5.2 allows remote attackers to have unspecified impact via a negative data size value, which triggers a heap-based buffer overflow.

A vulnerability in smtplib allowing MITM attacker to perform a startTLS stripping attack. smtplib does not seem to raise an exception when the remote end (smtp server) is capable of negotiating starttls but fails to respond with 220 (ok) to an explicit call of SMTP.starttls(). This may allow a malicious MITM to perform a startTLS stripping attack if the client code does not explicitly check the response code for startTLS.

CPython (aka Python) up to 2.7.13 is vulnerable to an integer overflow in the PyStringDecodeEscape function in stringobject.c, resulting in heap-based buffer overflow (and possible arbitrary code execution)