A vulnerability in the package_index module of pypa/setuptools versions up to 69.1.1 allows for remote code execution via its download functions. These functions, which are used to download packages from URLs provided by users or retrieved from package index servers, are susceptible to code injection. If these functions are exposed to user-controlled inputs, such as package URLs, they can execute arbitrary commands on the system. The issue is fixed in version 70.0.
Created buku tracking bugs for this issue: Affects: fedora-all [bug 2298673] Created cura tracking bugs for this issue: Affects: fedora-all [bug 2298674] Created limnoria tracking bugs for this issue: Affects: epel-all [bug 2298672] Created pypy tracking bugs for this issue: Affects: fedora-all [bug 2298675] Created python-setuptools_scm tracking bugs for this issue: Affects: fedora-40 [bug 2298671] Created qcoro tracking bugs for this issue: Affects: fedora-all [bug 2298676]
The main part of the PR fixing the vulnerability is the switch from os.system("git clone …") to subprocess.check_call(["git", "clone", …]).
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:5000 https://access.redhat.com/errata/RHSA-2024:5000
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:5002 https://access.redhat.com/errata/RHSA-2024:5002
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:5040 https://access.redhat.com/errata/RHSA-2024:5040
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Red Hat Enterprise Linux 8.4 Telecommunications Update Service Via RHSA-2024:5078 https://access.redhat.com/errata/RHSA-2024:5078
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:5084 https://access.redhat.com/errata/RHSA-2024:5084
FEDORA-2024-247e9ba33a (python-setuptools-69.0.3-4.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:5137 https://access.redhat.com/errata/RHSA-2024:5137
FEDORA-2024-9ed182a5d3 (python-setuptools-67.7.2-8.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:5279 https://access.redhat.com/errata/RHSA-2024:5279
Are the upgrades expected to be shipped in the registry.redhat.io/rhel9-2-els/rhel:9.2 image?
(In reply to aleskandro from comment #15) > Are the upgrades expected to be shipped in the > registry.redhat.io/rhel9-2-els/rhel:9.2 image? This is a high-severity vulnerability and RHEL 9.2 is still supported so the answer is yes. python-setuptools is already fixed, the update for python3.11-setuptools is in progress.
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions Via RHSA-2024:5389 https://access.redhat.com/errata/RHSA-2024:5389
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:5532 https://access.redhat.com/errata/RHSA-2024:5532
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:5531 https://access.redhat.com/errata/RHSA-2024:5531
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:5533 https://access.redhat.com/errata/RHSA-2024:5533
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:5530 https://access.redhat.com/errata/RHSA-2024:5530
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:5534 https://access.redhat.com/errata/RHSA-2024:5534
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:5962 https://access.redhat.com/errata/RHSA-2024:5962
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:6220 https://access.redhat.com/errata/RHSA-2024:6220
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:6311 https://access.redhat.com/errata/RHSA-2024:6311
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:6312 https://access.redhat.com/errata/RHSA-2024:6312
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2024:6309 https://access.redhat.com/errata/RHSA-2024:6309
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Red Hat Enterprise Linux 8.4 Telecommunications Update Service Via RHSA-2024:6488 https://access.redhat.com/errata/RHSA-2024:6488
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.0 Update Services for SAP Solutions Via RHSA-2024:6612 https://access.redhat.com/errata/RHSA-2024:6612
This issue has been addressed in the following products: Red Hat Enterprise Linux 9.2 Extended Update Support Via RHSA-2024:6611 https://access.redhat.com/errata/RHSA-2024:6611
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extended Lifecycle Support Via RHSA-2024:6661 https://access.redhat.com/errata/RHSA-2024:6661
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Extended Lifecycle Support Via RHSA-2024:6662 https://access.redhat.com/errata/RHSA-2024:6662
This issue has been addressed in the following products: Red Hat Enterprise Linux 9 Via RHSA-2024:6726 https://access.redhat.com/errata/RHSA-2024:6726
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.2 Advanced Update Support Via RHSA-2024:6907 https://access.redhat.com/errata/RHSA-2024:6907
This issue has been addressed in the following products: Service Interconnect 1.4 for RHEL 9 Via RHSA-2024:7213 https://access.redhat.com/errata/RHSA-2024:7213
This issue has been addressed in the following products: Service Interconnect 1 for RHEL 9 Via RHSA-2024:7374 https://access.redhat.com/errata/RHSA-2024:7374
This issue has been addressed in the following products: Red Hat OpenShift Container Platform 4.17 Via RHSA-2024:7922 https://access.redhat.com/errata/RHSA-2024:7922
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Telecommunications Update Service Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Via RHSA-2024:8172 https://access.redhat.com/errata/RHSA-2024:8172
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:8173 https://access.redhat.com/errata/RHSA-2024:8173
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.4 Telecommunications Update Service Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions Via RHSA-2024:8170 https://access.redhat.com/errata/RHSA-2024:8170
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Advanced Mission Critical Update Support Red Hat Enterprise Linux 8.6 Update Services for SAP Solutions Red Hat Enterprise Linux 8.6 Telecommunications Update Service Via RHSA-2024:8171 https://access.redhat.com/errata/RHSA-2024:8171
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:8168 https://access.redhat.com/errata/RHSA-2024:8168
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.8 Extended Update Support Via RHSA-2024:8179 https://access.redhat.com/errata/RHSA-2024:8179
Maybe I'm missing something. I'm completely clear that this issue is fixed for Python 3.11 and for python-setuptools... what about RedHat UBI 9 where python3-setuptools is installed, it's Python 3.9, and python3-setuptools is these versions (but NOT python3.11-setuptools): python3-setuptools-wheel-53.0.0-12.el9_4.1.noarch python3-setuptools-53.0.0-12.el9_4.1.noarch These packages are depended upon by dnf and therefore cannot be removed/uninstalled. Any work on getting RedHat UBI 9 to a version of DNF that uses a version of python3-setuptools that is above the vulnerable versions?
When we fix a vulnerability, there are usually two ways how to do it: * update package to a version containing the fix already, or * backport the patch to an older version we have in RHEL. The first one is better for new releases of RHEL or packages with limited support. The second one is better for already released versions of RHEL as it's safer because it does not bring unintended changes along the way. This CVE is an example of that. As you can see here: https://access.redhat.com/errata/RHSA-2024:5534, we have backported the patch to the build you've mentioned. Because it's not a rebase, there is no need to change the package's version. When verifying whether a vulnerability is fixed in one of Red Hat's components, checking just the version number is not enough. You can either search for released advisories or check the changelog of the package you have installed: [root@df0ea19337a7 /]# rpm -qv python3-setuptools python3-setuptools-53.0.0-12.el9_4.1.noarch [root@df0ea19337a7 /]# rpm -q --changelog python3-setuptools * Wed Jul 24 2024 Lumír Balhar <lbalhar> - 53.0.0-12.1 - Security fix for CVE-2024-6345 Resolves: RHEL-50466 * Wed Jan 11 2023 Charalampos Stratakis <cstratak> - 53.0.0-12 - Security fix for CVE-2022-40897 Resolves: rhbz#2158559 … Hope this helps.
@lbalhar this is EXTREMELY helpful, thank you. A couple of residual questions: 1) The version number 53.0.0 make sense to me. The -12 or -12.1 kinda make sense; these would be kinda like "patches" for version 53.0.0. But what does it mean when you have the version "-53.0.0-12.el9_4.1.noarch.rpm"... is the "4.1" here referring to the version of RedHat (9... 4.1?). To put it more directly... 2) If I have "python3-setuptools-wheel-53.0.0-12.el9.noarch" and "python3-setuptools-53.0.0-12.el9.noarch" installed... do I have this item patched, or not? It IS version 53.0.0-12, but it does not include the 4.1, and that's the version mentioned in the RHSA you pointed me to. 3) Is any of this written down somewhere that's not a Bugzilla comment? Like if I have a team member coming onboard and I need to instruct them about how to apply this analysis when creating containers, is there a docs page or manual page I can point them to that indicates that RHSAs are covering these issues for RedHat's copy of Python3? 4) Is it fair to interpret things that apply to RedHat 9 as also applying to RedHat's UBI 9 base image? Always? 5) This is not a major concern but a curiosity: why is RedHat sticking with setuptools v53 when this package is now up to 75 (https://pypi.org/project/setuptools/)? Am I right in assuming it's a dependency of yum/dnf? At what point does patching a version from 2021 (https://pypi.org/project/setuptools/#history) stop making sense?
(In reply to Ben Smith (IBM) from comment #51) > @lbalhar this is EXTREMELY helpful, thank you. A couple of > residual questions: This is getting into the packaging details but why not. > 1) The version number 53.0.0 make sense to me. The -12 or -12.1 kinda make > sense; these would be kinda like "patches" for version 53.0.0. But what > does it mean when you have the version "-53.0.0-12.el9_4.1.noarch.rpm"... is > the "4.1" here referring to the version of RedHat (9... 4.1?). To put it > more directly... After the version number, we have something called a release number with a dist tag. When building something new for the future minor version we bump the release number and the dist tag is el9 in this case. So the fixed version in RHEL 9.5 will be python-setuptools-53.0.0-13.el9 Because we have to preserve the upgrade path between minor releases, we don't usually bump the release when building something for already released RHEL (9.4 in this case). Also, the dist tag for releases already out contains both major and minor number: el9_4. So, for RHEL 9.4, instead of going from -12.el9_4 to -13.el9_4, we use -12.el9_4.1. That way, even if the version is the same, the release numbers in newer RHEL releases are always higher and a downgrade or a regression during upgrades cannot happen. > 2) If I have "python3-setuptools-wheel-53.0.0-12.el9.noarch" and > "python3-setuptools-53.0.0-12.el9.noarch" installed... do I have this item > patched, or not? It IS version 53.0.0-12, but it does not include the 4.1, > and that's the version mentioned in the RHSA you pointed me to. No, your version is vulnerable. It depends on the system you are using. If it's RHEL 9.4, you should upgrade to the version mentioned in the RHSA. If you are running Centos Stream, the patched version python-setuptools-53.0.0-13.el9 is already available. Another possibility is to upgrade to RHEL 9.5 once available. > 3) Is any of this written down somewhere that's not a Bugzilla comment? > Like if I have a team member coming onboard and I need to instruct them > about how to apply this analysis when creating containers, is there a docs > page or manual page I can point them to that indicates that RHSAs are > covering these issues for RedHat's copy of Python3? Nothing I know about, sorry. But I'm an engineer and the questions about the documentation are better for customer support. But you can find something online, for example: https://access.redhat.com/security/updates/advisory/ > 4) Is it fair to interpret things that apply to RedHat 9 as also applying to > RedHat's UBI 9 base image? Always? Yes. UBI content is based on what's going into RHEL. Always. > 5) This is not a major concern but a curiosity: why is RedHat sticking with > setuptools v53 when this package is now up to 75 > (https://pypi.org/project/setuptools/)? Am I right in assuming it's a > dependency of yum/dnf? At what point does patching a version from 2021 > (https://pypi.org/project/setuptools/#history) stop making sense? Because this is an enterprise distribution and enterprise customers want stability more than anything. If you want more fresh software, we are working on the new setuptools for Fedora Linux. A very simplified promise might sound like: You can install our enterprise distro and your applications on top, and we promise to keep it stable without breaking backward compatibility while still fixing security vulnerabilities for years. Of course there are many nuances and different levels of support etc. That's the reason for backporting patches rather than upgrading to the latest versions - when you backport a patch to fix a security vulnerability, the risk of breaking something is much smaller than when you upgrade. This discussion seems to be helpful but I'm not sure it's interesting for all recipients of notifications of this bug so if you have any more questions, feel free to send me an e-mail.