In Python3's Lib/test/multibytecodec_support.py CJK codec tests call eval() on content retrieved via HTTP. Affected versions include Python 3.10, Python 3.9, Python 3.8, Python 3.7, Python 3.6.
References: Upstream bug: https://bugs.python.org/issue41944 Patches: https://github.com/python/cpython/commit/2ef5caa58febc8968e670e39e3d37cf8eef3cab8 (master) https://github.com/python/cpython/commit/b664a1df4ee71d3760ab937653b10997081b1794 (3.9) https://github.com/python/cpython/commit/6c6c256df3636ff6f6136820afaefa5a10a3ac33 (3.8) https://github.com/python/cpython/commit/43e523103886af66d6c27cd72431b5d9d14cd2a9 (3.7) https://github.com/python/cpython/commit/e912e945f2960029d039d3390ea08835ad39374b (3.6)
(In reply to Todd Cullum from comment #0) > In Python3's Lib/test/multibytecodec_support.py CJK codec tests call eval() > on content retrieved via HTTP. Affected versions include Python 3.10, Python > 3.9, Python 3.8, Python 3.7, Python 3.6. I can see 3 cases where the test suite is being run: 1. During build of each Python package - network connection is disabled, so this does not lead to a security vulnerability. 2. During testing by our QE - I'm not sure if network is enabled here (CC lzachar), could be a problem. 3. When a user manually runs the test suite from the python3*-test package. In my opinion, case 3 is not serious enough to warrant active fixing (SCL/AppStream Pythons will get the fix eventually through a rebase). Does that make sense Todd?
Created mingw-python3 tracking bugs for this issue: Affects: fedora-all [bug 1890227] Created python3 tracking bugs for this issue: Affects: fedora-all [bug 1890221] Created python35 tracking bugs for this issue: Affects: fedora-all [bug 1890222] Created python36 tracking bugs for this issue: Affects: fedora-all [bug 1890223] Created python37 tracking bugs for this issue: Affects: fedora-all [bug 1890224] Created python38 tracking bugs for this issue: Affects: fedora-all [bug 1890225] Created python39 tracking bugs for this issue: Affects: fedora-all [bug 1890226]
The content received via HTTP is fetched from http://www.pythontest.net/ -- HTTPS is not used and if the content is forged by an attacker (e.g. MITM) it is executed. In Fedora, the test suite is executed on several occasions: - offline, in Koji, during package build - safe - offline, in mock, when rebuilding the package - safe - online, in mock --enable-network or with plain rpmbuild, but the test suite is not executed with the network resource enabled - safe - online, by executing pythonX.Y -m test -u network - not safe I consider the group of users who would run the test suite locally from the installed package so small that I'm inclined to close the Python 3.6+ Fedora bugs as UPSTREAM.
(In reply to Miro Hrončok from comment #7) > The content received via HTTP is fetched from http://www.pythontest.net/ -- > HTTPS is not used and if the content is forged by an attacker (e.g. MITM) it > is executed. > > In Fedora, the test suite is executed on several occasions: > > - offline, in Koji, during package build - safe > - offline, in mock, when rebuilding the package - safe > - online, in mock --enable-network or with plain rpmbuild, but the test > suite is not executed with the network resource enabled - safe > - online, by executing pythonX.Y -m test -u network - not safe > > I consider the group of users who would run the test suite locally from the > installed package so small that I'm inclined to close the Python 3.6+ Fedora > bugs as UPSTREAM. Agreed.
For clarity (if we decided not to close this as wontfix on 3.5 and 3.4), the 3.6 commit applies to 3.5 and 3.4 without modifications, however, it uses one f-string.
Mitigation: In versions of Python shipped with Red Hat Enterprise Linux and Red Hat Software Collections, the flaw can be mitigated by not running the python tests with network resources enabled. By default, the tests are not run with network resources enabled. Ensure that `-u network` or `-uall` are not passed as options to `python -m test`. For more information on how these commands work, see [1]. 1. https://docs.python.org/3/library/test.html
As of Red Hat Quay 3.4 the python runtime will be consumed from RHEL. Currently releases up to 3.3 won't get fixes for this moderate issue.
Statement: As of Red Hat Quay 3.4 the python runtime will be consumed from RHEL. Currently releases up to 3.3 won't get fixes for this moderate issue.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:1633 https://access.redhat.com/errata/RHSA-2021:1633
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-27619
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS Via RHSA-2021:3252 https://access.redhat.com/errata/RHSA-2021:3252
This issue has been addressed in the following products: Red Hat Software Collections for Red Hat Enterprise Linux 7 Red Hat Software Collections for Red Hat Enterprise Linux 7.7 EUS Via RHSA-2021:3254 https://access.redhat.com/errata/RHSA-2021:3254
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2021:4151 https://access.redhat.com/errata/RHSA-2021:4151
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 (python38:3.8/python38) via RHSA-2021:4162 https://access.redhat.com/errata/RHSA-2021:4162