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
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().
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
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.