Mailman 3 March 2017 - Security-SIG

Python Vulnerabilities: Vulnerable Python versions added
by Victor Stinner March 23, 2017

March 23, 2017

Hi, I just added the list of vulnerable Python versions to my report: http://python-security.readthedocs.io/vulnerabilities.html So I checked the status of backports, and I identified one last vulnerability not fixed in Python 3.4 yet: HTTP directory traversal on Windows. I proposed a cherry-pick: https://github.com/python/cpython/pull/782 Python 3.2 and 3.3 lack a lot of fixes, but the last release was in 2014. Fixes were backported in the meanwhile, but no new security version was released since that time. gettext: FIXME 3.2 3.3 fixed: no release yet Sweet32 3.4 fixed: no release yet HTTPoxy attack: 3.2 and 3.3 FIXME 3.2 3.3 fixed: no release yet smtplib TLS striping FIXME 3.2 3.3 fixed: no release yet HTTP directory traversal FIXME 3.2 FIXME 3.3 FIXME 3.4 => https://github.com/python/cpython/pull/782 Expat 2.1.1 FIXME 3.2 FIXME 3.3 zipimporter overflow FIXME 3.2 3.3 fixed, no release yet HTTP Header injection FIXME 3.2 FIXME 3.3 Validate TLS certificate 3.2 and 3.3 vulnerable: no plan to backport the feature SSL: NULL byte 3.3 fixed: no release yet match_hostname IDNA FIXME 3.2 xmlrpc gzip decode 3.2 fixed in 2014: no release yet 3.3 fixed: no release yet Victor

1 0

Archives (.tar or .zip) with absolute paths
by Victor Stinner March 10, 2017

March 10, 2017

Hi, I noticed that "python3 -m tarfile -x archive.tar" uses absolute paths by default, whereas the UNIX tar command doesn't by default. The UNIX tar command requires to add explicitly --absolute-paths (-P) option. The tarfile and zipfile modules (maybe also some others, I didn't check) contain warnings absolute paths and paths containing "..". Why not ignoring "/" at start of filenames *by default*? By backward compatibility? I suggest to add a boolean absolute_path option to tarfile and zipfile and disable it by default in the CLI. The question is what should be the default value for the Python API. I suggest to use absolute_path=False by default for safety. Example to create such archive. See that tar also removes "/" by default and requires to pass explicitly -P: $ cd $HOME # /home/haypo $ echo TEST > test $ tar -cf test.tar /home/haypo/test tar: Removing leading `/' from member names $ rm -f test.tar $ tar -P -cf test.tar /home/haypo/test $ rm -f test Extracting such archive using tar is safe *by default*: $ mkdir z $ cd z $ tar -xf ~/test.tar tar: Removing leading `/' from member names $ find . ./home ./home/haypo ./home/haypo/test Extracting such archive using Python is unsafe: $ python3 -m tarfile -e ~/test.tar $ cat ~/test TEST $ pwd /home/haypo/z Python creates files outside the current directory which is unsafe, wheras tar doesn't. Victor

3 7

New report of Python vulnerabilities
by Victor Stinner March 10, 2017

March 10, 2017

Hi, I made major enhancements in my tool to generate reports on Python vulnerabilities. * A timeline is now automatically generated using the different dates: initial report date, disclosure date, commits, Python releases, etc. * CVE details are now downloaded automatically, so it's not more filled manually in the YAML file. * Each vulnerability has now its own page Good example showing everything altogether, the Sweet32 attack: http://python-security.readthedocs.io/vuln/cve-2016-2183_sweet32_attack_des… The next step is to make sure that all maintained branches got a fix! I should enhance the tool to compute the list of vulnerable Python versions. Victor

1 0

HTML page of Python security vulnerabilities
by Victor Stinner March 10, 2017

March 10, 2017

Hi, I wrote a tool to generate an HTML report on Python security vulnerabilities. It takes the following YAML file as input: https://github.com/haypo/python-security/blob/master/vulnerabilities.yml And Python release dates, file written manually from Misc/NEWS: https://github.com/haypo/python-security/blob/master/python_releases.txt The output is the HTML page: http://python-security.readthedocs.io/en/latest/vulnerabilities.html For each vulnerability, you have a description and a list of links. >From a list of commits, the tool computes the fixed Python and the number of days Python was vulnerable. Can you please check data of my two input files? What do you think of the page? Is it useful? TODO: * fix render_doc.py to support multiple lines in the table * add title to links * find the YAML syntax for "Issue #26657" :-) Current, #xxx is ignored since it's seen as a comment * maybe document in the YAML file how the Disclosure date was chosen Maybe I should add a "vulnerable" column to list Python versions which are vulnerable. If you consider the data useful and the data are double checked, the next step will to announce it. Later, I plan to slowly fill vulnerabilities.yml with recent vulnerabilities, and then with older vulnerabilities. FYI a few months ago, I generated the page manually, but quickly I realized that it's painful to compute all data and also to maintain manually such list. My old page: http://haypo-notes.readthedocs.io/python_security.html Victor

3 6

Patching ssl.py to workaround ssl lack of relocability
by David Cournapeau March 2, 2017

March 2, 2017

Hi there, This is hopefully the right mailing for this question. We are shipping our own python interpreter in our product, and following some discussions on https://mail.python.org/pipermail/python-dev/2017-January/147282.html, we understand shipping the certificate from certifi in our python is the best approach on Linux/OS X. Unfortunately, ssl hardcodes at compilation time the default location of certificate. I could workaround this at the python level by patching ssl.SSLContext.load_default_certs to look as follows: def load_default_certs(...): .... if sys.platform == "win32": ... else: prefix = os.path.normpath(sys.prefix) default_cert = os.path.join(prefix, "ssl", "cert.pem") if os.path.isfile(default_cert): self.load_verify_locations(default_cert) else: self.set_default_verify_paths() While this seems to work, my lack of knowledge in all things related to security and ssl in particular makes me worry to patch anything in there. Is this a sane approach ? If not, is there a better way ? Thank you, David

3 4