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.
A security flaw was found in the way handlers for ftp:// and file:// URL schemes in the Python urllib and urllib2 extensible libraries processed the urllib open URL request. A remote attacker could use this flaw to access sensitive information or cause a denial of service (excessive CPU and memory use) of a Python web application, processing URLs, via a specially-crafted urllib open URL request.
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
Description of problem:
When using SimpleXMLRPCServer from the standard library, if a client connection is closed before the complete request body has been received the server will enter an infinite loop consuming memory.
Version-Release number of selected component (if applicable):
python-2.6.6-29.el6.x8664
How reproducible:
always
Steps to Reproduce:
1. Start the server: >> import SimpleXMLRPCServer, SocketServer >> class Server(SocketServer.ThreadingMixIn, SimpleXMLRPCServer.SimpleXMLRPCServer): pass ... >> Server(('0.0.0.0', 12345)).serveforever()
2. Simulate a malicious or flakey client: $ echo -e 'POST /RPC2 HTTP/1.0\r\nContent-Length: 100\r\n\r\nlol bye' | nc localhost 12345 ^C
Actual results:
Server goes nuts, with a thread stuck in an infinite loop eating memory.
Expected results:
Bad request is discarded.
Additional info:
The bug is in /usr/lib64/python2.6/SimpleXMLRPCServer.py at line 453:
# Get arguments by reading body of request. # We read this in chunks to avoid straining # socket.read(); around the 10 or 15Mb mark, some platforms # begin to have problems (bug #792570). maxchunksize = 1010241024 sizeremaining = int(self.headers["content-length"]) L = [] while sizeremaining: chunksize = min(sizeremaining, maxchunksize) L.append(self.rfile.read(chunksize)) sizeremaining -= len(L[-1]) data = ''.join(L)
This code does not correctly handle EOF from self.rfile.read().
A flaw was found in the way ssl.matchhostname() from the Python SSL module checked the hostname's identity when handling certificates that contain hostnames with NULL bytes. An attacker could potentially exploit this flaw to conduct man-in-the-middle attacks to spoof SSL servers. Note that to exploit this issue, an attacker would need to obtain a carefully-crafted certificate signed by an authority that the client trusts.
References:
http://bugs.python.org/issue18709 http://bugs.python.org/file31241/CVE-2013-4073py34.patch http://bugs.python.org/file31242/CVE-2013-4073py33.patch http://bugs.python.org/file31243/CVE-2013-4073py27.patch
It was reported [1] that distutils would create ~/.pypirc insecurely. There is a race from the time the user's username and password is written to the file to when it is chmod'd with appropriate permissions.
Typically, a user's home directory will be created with default 0700 permissions which would not allow for a local attacker to obtain access to this file during the race window, however if a user were to make their home directory 0755 they could be susceptible to this race.
One solution would be to use tempfile.mkstemp() to create the file and then move it in place.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650555