Mailman 3 - Security-SIG

Which CVSS Severity and Metrics version should be used? 2 or 3?
by Victor Stinner 21 Feb '21

21 Feb '21

Hi, There are discussion on the python-dev list about the ctypes CVE-2021-3177 vulnerability and its severity. I discovered at https://nvd.nist.gov/vuln/detail/CVE-2021-3177 that there is a version 3 of the CVSS score. The ctypes CVE-2021-3177 got a score of 9.8 CRITICAL in its version 3, but a score of 7.5 HIGH in its version 2. Should we only display the score versioin 3? Or display both? On my python-security website, I use "http://cve.circl.lu/api/cve/<CVE number>" API which returns CVE data as JSON. It seems to provide CVSS score version 2. Example with CVE-2021-3177: "cvss": 7.5, "cvss-time": "2021-02-13T03:15:00", "cvss-vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P", This score is rendered in the CVE section: https://python-security.readthedocs.io/vuln/ctypes-buffer-overflow-pycarg_r… I found https://nvd.nist.gov/vuln/data-feeds list of APIs which returns data of *all* CVEs (per year) as JSON. Does someone know an API to retrieve CVE data as JSON of a single CVE which includes CVSS version 3? If anyone wants to help me, look at the "render_doc.py" script at: https://github.com/vstinner/python-security/ Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

PSRT's page link is broken on the description
by Felipe Rodrigues 06 Jul '20

06 Jul '20

Hello all! Just noticed that the link to the Python Security Response Team on this list's info box points to https://www.python.org/news/security that lands in https://www.python.org/blogs/. That page does not contain any obvious reference to the PSRT page. I think it would be better to link it to https://www.python.org/dev/security/ --Felipe Bidu

3 2

PEP 458: Secure transport independent download integrity for PyPI packages
by Sumana Harihareswara 12 Feb '20

12 Feb '20

This is more of a PyPI security discussion than a core Python issue, but I figured I'd bring attention to it anyway: https://discuss.python.org/t/pep-458-surviving-a-compromise-of-pypi/2648/ The PEP authors are revising the proposed summary, title, etc., per https://github.com/secure-systems-lab/peps/blob/c13384a4fac6822626abb7e09ab… : > Attacks on software repositories are common, even in organizations with very good security practices__. The resulting repository compromise allows an attacker to edit all files stored on the repository and sign these files using any keys stored on the repository (online keys). In many signing schemes (like TLS), this access allows the attacker to replace files on the repository and make it look like these files are coming from PyPI. Without a way to revoke and replace the trusted private key, it is very challenging to recover from a repository compromise. In addition to the dangers of repository compromise, software repositories are vulnerable to an attacker on the network (MITM) intercepting and changing files. These and other attacks on software repositories are detailed here__. This PEP aims to protect users of PyPI from compromises of the integrity, consistency and freshness properties of PyPI packages, and enhances compromise resilience, by mitigating key risk and providing mechanisms to recover from a compromise of PyPI or its signing keys. In addition to protecting direct users of PyPI, this PEP aims to provide similar protection for users of PyPI mirrors. > To provide compromise resilient protection of PyPI, this PEP proposes the use of The Update Framework [2]_ (TUF). ..... > This PEP describes changes to the PyPI infrastructure that are needed to ensure that users get valid packages from PyPI. ... > __ https://github.com/theupdateframework/pip/wiki/Attacks-on-software-reposito… > __ https://theupdateframework.github.io/security.html Discussion should probably be directed to the Discourse thread at discuss.python.org ; this is just a heads-up. -- Sumana Harihareswara Changeset Consulting sh(a)changeset.nyc

1 1

Re: [Security-announce]CVE-2020-8315: Windows 7 DLL hijack
by Marlon Luis Petry 29 Jan '20

29 Jan '20

Steve Dower, Thanks for sharing this with us. Any workaround to mitigate this? Cheers, Marlon Petry On Tue, Jan 28, 2020, 23:48 Steve Dower <steve.dower(a)python.org> wrote: > A DLL hijacking vulnerability has been discovered in CPython 3.6, 3.7 > and 3.8 when running on Windows 7 or earlier. > > An attacker who is able to place a DLL "api-ms-win-core-path-l1-1-0.dll" > earlier on the DLL search path than the System32 directory could cause > their file to be loaded and executed at interpreter startup instead of > the system one. > > Prior to Windows 7, this file does not exist and may be placed anywhere > on the search path. After Windows 7, the DLL is loaded directly from its > API set and not using the search path. Only Windows 7 is impacted. > > Patches to ensure that only the System32 copy of the file is loaded are > linked from the bug page below. The next release of each version > (3.6.11, 3.7.7, 3.8.2) will include the fixes. Python 3.9 does not > support Windows 7, and so is unimpacted. > > Note that this attack will likely work against other applications on > Windows 7, and it is not unique to CPython. Upgrading to a supported > operating system is recommended. > > CVE page: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8315 > Bug page: https://bugs.python.org/issue39401 > > Cheers, > Steve Dower and the Python Security Response Team > _______________________________________________ > Security-announce mailing list -- security-announce(a)python.org > To unsubscribe send an email to security-announce-leave(a)python.org > https://mail.python.org/mailman3/lists/security-announce.python.org/ >

2 1

Table of Python Vulnerabilities updated
by Victor Stinner 15 May '19

15 May '19

Hi, I updated the list of Python vulnerabilities: https://python-security.readthedocs.io/vulnerabilities.html I modified my code to support multiple CVE per vulnerability, example with 8 CVE: https://python-security.readthedocs.io/vuln/multiple-integer-overflows-appl… I added a "slug": ascii unique identifier for each vulnerability. Maybe we need to create our own vulnerability numbers rather than using CVE, bugs.python.org bug number or a slug. It might ease to properly identify a vulnerability. Some old issues have no bpo number (fixed directly into the code without creating an issue): https://python-security.readthedocs.io/vuln/smtplib-tls-stripping.html Deciding how we identify vulnerabilities is the main blocker issue to migrate https://python-security.readthedocs.io/ to https://security.python.org/ It would be nice to make this website more official to collect "official" information about Python security. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

Move https://python-security.readthedocs.io/ to python.org?
by Victor Stinner 21 Feb '19

21 Feb '19

Hi, I maintain a list of CPython vulnerabilities. It's a long YAML file which is used to compute multiple information: * which Python versions are vulnerable * build a timeline to understand when the vulnerability has been discovered, when it has been made public, when it has been fixed I care of public Python releases, but my tool renders when a change is merged in a branch. I also added some notes about security, but they are not well organized. One day, Ernest asked me if I would like to move my website to python.org. Today, I saw that my website is referrenced from a very official Red Hat vulnerability report: https://access.redhat.com/security/cve/cve-2019-5010 One of my main issue is to get an unique identifier for each vulnerability. Some vulnerabilities have no issuse associated. Some have a CVE, some others don't. Maybe we need a Python registry which would be reset each new year, like PYTHON-2009-001? Right now, the "identifier" is the URL, like "ssl-crl-dps-dos" for "CVE-2019-5010" also known as "TALOS-2018-0758": https://python-security.readthedocs.io/vuln/ssl-crl-dps-dos.html I have no strict rule to decide which bugs are qualified as vulnerabilities and should be tracked by this website. For example, pickle.load() denial-of-service has been qualified as a regular "bug" by Serhiy Storchaka, but the bug got a CVE: https://python-security.readthedocs.io/vuln/pickle-load-dos.html I decided to mention it because of the CVE. Even if pickle is known to be unsecure... well... people use it, and I would prefer to fix known DoS :-) If someone would like to move python-security to python.org, I would suggest to: * Decide how to assign unique identifiers * Decide if we move the whole website and only the vulnerabilities So, what do you think? Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

Script for testing Python vulnerabilities
by Victor Stinner 20 Feb '19

20 Feb '19

Hi, I wrote a set of scripts to check for known Python vulnerabilities: https://github.com/vstinner/python-security/tree/master/check-python-vuln Clone the repository, go to check-python-vuln/ subdirectory, and run: "python check-python-vuln.py" I wrote this project to help me to check easily which vulnerabilities have been fixed or not on a specific Python binary. Right now, I only implemented checks for 4 vulnerabilities... they are many more known vulnerabilities! https://python-security.readthedocs.io/vulnerabilities.html Contact me if you want to help to write tests for more vulnerabilities ;-) I'm not sure that it's possible to write a functional test for all vulnerabilities :-( For example, "CVE-2018-20406: pickle.load denial of service" allocates too much memory with and without the fix, at least using the attached "poc" file. check-python-vuln.py uses functional tests rather than just testing the Python version, because in Fedora and RHEL, we backport security fixes without changing the Python version (especially in RHEL). Example with Python 2 on up to date Fedora 29: --- $ python2 check-python-vuln.py Check: SSL CRL DPS DoS (CVE-2019-5010) Check: gettext.c2py (bpo-28563) Check: SLL NUL in subjectAltNames (CVE-2013-4238) Check: Hash DoS (CVE-2012-1150) Result for /usr/bin/python2 (2.7.15): * SSL CRL DPS DoS (CVE-2019-5010): VULNERABLE * gettext.c2py (bpo-28563): fixed * SLL NUL in subjectAltNames (CVE-2013-4238): fixed * Hash DoS (CVE-2012-1150): fixed Your Python 2.7.15 has 1 KNOWN VULNERABILITY!!! --- Note: My team decided that the "SSL CRL DPS DoS (CVE-2019-5010)" can wait for Python 2.7.16 release. It doesn't deserve an urgent fix. Example with Python 3.0: --- $ ~/prog/python/3.0/python check-python-vuln.py Check: SSL CRL DPS DoS (CVE-2019-5010) Check: gettext.c2py (bpo-28563) Check: SLL NUL in subjectAltNames (CVE-2013-4238) Check: Hash DoS (CVE-2012-1150) Result for /home/vstinner/prog/python/3.0/python (3.0.1): * SSL CRL DPS DoS (CVE-2019-5010): CHECK_ERROR (CHECK FAILED: missing _ssl module: No module named _ssl) * gettext.c2py (bpo-28563): VULNERABLE * SLL NUL in subjectAltNames (CVE-2013-4238): CHECK_ERROR (CHECK FAILED: missing _ssl module: No module named _ssl) * Hash DoS (CVE-2012-1150): VULNERABLE CHECK ERROR :-( Your Python 3.0.1 has 2 KNOWN VULNERABILITIES!!! --- Note: Fedora 29 uses OpenSSL 1.1.1 but Python 3.0 isn't compatible with this OpenSSL version (ssl compilation failed). I should maybe try compat-openssl10 to test my tool on a fully working Python 3.0 (with ssl) :-) On the other side, python3 is safe: --- (...) All tested vulnerabilities are fixed in your Python 3.7.2 :-) --- Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

python-security.readthedocs.io updated
by Victor Stinner 21 Jan '19

21 Jan '19

Hi, I reworked my script generating the list of Python vulnerabilities to be able to list commits which are not part of a public release yet. I added recent vulnerabilities: * CVE-2019-5010: TALOS-2018-0758 SSL CRL distribution points Denial of Service * CVE-2018-20406: pickle.load denial of service * CVE-2018-14647: _elementree C accelerator doesn’t call XML_SetHashSalt() https://python-security.readthedocs.io/vulnerabilities.html I wrote this website to be help tracking if known vulnerabilities are fixed in all supported branches (2.7, 3.4-3.8) It's not the case for the 3 latest vulnerabilities yet. I will make sure that they are fixed. Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

Subscriptions to Security-announce
by Victor Stinner 07 Jan '19

07 Jan '19

Hi, I got an email from someone who couldn't subscribe to the security-announce mailing list: https://mail.python.org/mailman3/lists/security-announce.python.org/ I found 30 pending subscriptions. I don't understand why there were so many pending subscriptions, so I just removed all of them. The subscription should be approved by the subscriber, the admin don't need to moderate them. By the way, you might communicate more on this list which didn't get any email last months... https://mail.python.org/archives/list/security-announce@python.org/ Victor -- Night gathers, and now my watch begins. It shall not end until my death.

1 0

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. Many thanks to Alexey Izbyshev for the report, and helping us work through developing the patch. Cheers, Steve Dower on behalf of the Python Security Response team

1 0