Mailman 3 - Security-SIG

CVE-2018-1000117: Buffer overflow vulnerability in os.symlink on Windows
by Steve Dower 07 Mar '18

07 Mar '18

On February 27th, 2018, the Python Security Response team was notified of a buffer overflow issue in the os.symlink() method on Windows. The issue affects all versions of Python between 3.2 and 3.6.4, including the 3.7 beta releases. It has been patched for the next releases of 3.4, 3.5, 3.6 and 3.7. Scripts may be vulnerable if they use os.symlink() on Windows and an attacker is able to influence the location where links are created. As os.symlink requires additional privileges, exploits using this vulnerability are more likely to result in escalation of privilege. Besides applying the fix to CPython, scripts can also ensure that the length of each path argument is less than 260, and if the source is a relative path, that its combination with the destination is also shorter than 260 characters. That is: assert (len(src) < 260 and len(dest) < 260 and len(os.path.join(os.path.dirname(dest), src)) < 260) os.symlink(src, dest) Scripts that explicitly pass the target_is_directory argument as True are not vulnerable. Scripts on Python 3.5 that use bytes for paths are not vulnerable, because of a combination of stack layout and added parameter validation, but will still not behave correctly for long paths. This vulnerability has been registered as CVE-2018-1000117, and patched in the commits listed below. This patch prevents the buffer overflow, but does not raise any new errors or enable the use of long paths when creating symlinks. master: http://hg.python.org/lookup/6921e73e33edc3c61bc2d78ed558eaa22a89a564 3.7: http://hg.python.org/lookup/96fdbacb7797a564249fd59ccf86ec153c4bb095 3.6: http://hg.python.org/lookup/baa45079466eda1f5636a6d13f3a60c2c00fdcd3 3.5: (not yet merged) 3.4: (not yet merged) See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000117 for the official record. Discussion to https://bugs.python.org/issue33001 or security-sig(a)python.org. Cheers, Steve Dower on behalf of the Python Security Response team

1 1

Backport critical bugfixes?
by Victor Stinner 29 Sep '17

29 Sep '17

Hi, What is the policy for "critical" bugfixes regarding to Python branches which only accept security fixes? I'm thinking at https://bugs.python.org/issue31095 "fix potential crash during GC". The bug was fixed in Python 3.5 while this change only accepted security fixes. Should we backport the fix to Python 3.3 and 3.4 as well? Victor

3 2

Fwd: List Settings Question
by Steve Barnes 26 Sep '17

26 Sep '17

I personally was very disappointed on signing up to the both this mailing list & security-announce to receive back an email containing my password in plain text with the promise of the same thing once a month unless I changed settings on the mail man site.. I would have thought that a security related list could provide better default practices than that! Is anybody else concerned about the idea? Steve Barnes. --- This email has been checked for viruses by AVG. http://www.avg.com

7 7

All known security vunerabilities have been fixed in all branches
by Victor Stinner 28 Jul '17

28 Jul '17

Hi, I have a good news: I checked and all known security vunerabilities have been fixed in the 6 maintained Python branches: 2.7, 3.3, 3.4, 3.5, 3.6 and master. While the YAML file of my python-security tool contains all commits, the webpage still shows vulnerable branches since we are now waiting for releases. My tool only cares of public releases. http://python-security.readthedocs.io/vulnerabilities.html The other good news is that many releases are scheduled in next weeks: * 3.3.7, 3.4.7 and 3.5.4 final: August 7, 2017 * 2.7.14 around mi-september (after the CPython sprint) After 2.7.14 release, the last vulnerable Python version will be 3.6.2 with the "urllib FTP protocol stream injection" vulnerability: http://python-security.readthedocs.io/vuln/urllib_ftp_protocol_stream_injec… While this bug is public since 2017-02-20, I'm still not sure about its severity. It doesn't seem to be an important one. Note: 3.3.7 will be the last release before 3.3 end of life. 3.5.4 will be the last binary release of the 3.5 branch. Victor

1 0

Vulnerability table updated for Python 3.6.2
by Victor Stinner 18 Jul '17

18 Jul '17

Hi, I updated my vulnerability table for the Python 3.6.2 release: http://python-security.readthedocs.io/vulnerabilities.html I also added bpo-30730: "Environment variables injection in subprocess on Windows". Sadly, we missed to fix the "urllib FTP protocol stream injection" vulnerability. Victor

1 0

Python Vulnerabilities: Vulnerable Python versions added
by Victor Stinner 23 Mar '17

23 Mar '17

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 10 Mar '17

10 Mar '17

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 10 Mar '17

10 Mar '17

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 10 Mar '17

10 Mar '17

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 02 Mar '17

02 Mar '17

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