-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[security][CVE-2020-27619] Python testsuite calls eval() on content received via HTTP #86110
Comments
As was reported by Florian Bruhin, Python testsuite calls eval() on content received via HTTP (in Lib/test/multibytecodec_support.py). |
I wonder if I should request a CVE for this as well? Just to make sure the word gets out to distributions/organizations/etc. running the Python testsuite, given that we can't be sure it which contexts this happens (and as it could be exploited by e.g. spoofing a WiFi network or so). |
I don't think that a CVE is justified. I don't know anyone running the Python test suite on production. Only developers of Python itself run Python. |
Oops: Only developers of Python itself run the Python test suite. |
That assumption is false. For starters, distribution packagers do: https://src.fedoraproject.org/rpms/python3.9/blob/master/f/python3.9.spec#_1168 When I build a Python from source (via an Arch User Repository package), I do as well, and so does anyone installing those packages by default. Anyone building with --enable-optimizations (PGO) will likely do so as well, though I'm not sure if that runs this part of the testsuite. |
I'm not saying that this issue is not a vulnerability, just that the scope is limited. By default, downloaded from the Internet are disabled. You have to opt-in for that using -u network (or -u all which enables the network resource) command line option of "./python -m test". Impacted:
Fedora packages are not impacted: no -u option is passed to the test suite.
PGO build is not impacted, it uses "./python -m test --pgo" (download is disabled). Moreover, multibyte codec checks are not run by this command (see Lib/test/libregrtest/pgo.py, only test_codecs of codec tests is run). |
Thanks for the clarification - I wasn't aware those tests aren't run by default. FWIW I found another place where a similar thing is done, though by chance it's probably not exploitable - see #66765. |
I agree that test_ucn is not exploitable, but it would be nice to harden it anyway. Extract of the code:
test_ucn downloads http://www.pythontest.net/unicode/13.0.0/NamedSequences.txt and calls checkletter() on each line, but first it ensures that unicodedata.lookup(seqname) works as expected. I don't see how it would be possible to inject arbitrary Python code in the 'seqname' variable without making unicodedata.lookup() to fail. |
I'm now tracking this vulnerability at: |
Since it's a security vulnerability, I created backports to 3.6 and 3.7 as well. |
Thanks for the fix Serhiy and thanks Florian Bruhin for the bug report! |
The CVE-2020-27619 has been assigned to this issue. |
Red Hat advisory: https://access.redhat.com/security/cve/CVE-2020-27619 |
@gvanrossum, is there anything else that needs to be done in this issue? |
Whoops, didn’t mean to reopen. This has happened a few times — I look at an issue, maybe subscribe, and it gets reopened? |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: