Vulnerability with setuptools < 70.0.0 (CVE-2024-6345)

[josumoreno-BP]

Hello,

I've seen CVE-2024-6345 report today. I was wondering if you plan to update setuptools at least on 3.11 images like you did in the past on #783.

Thank you

[LaurentGoderre]

Not that this only affects version 3.11 and under. Version 3.12 is not affected.

[johandebraak]

Could this also be fixed in the 3.10 images? Thank you

[guoard]

@LaurentGoderre Is it alright if we make the same change as in PR #783, specifically updating the setuptools version to 70.0.0? If so, I can create the pull request.

[tianon]

Current versions of setuptools in affected versions:

3.11.9: 65.5.1
3.10.14: 65.5.1
3.9.19: 58.1.0
3.8.19: 57.5.0

Do we have any idea how many breaking changes there are between even 65.5.1 and 70.0.0? Also, any idea whether cpython upstream plans to do a new release with a different version bundled, since their upstream artifacts are also affected?

[tianon]

I'll also link to #781 (comment) explicitly, as it's even more relevant here (where the proposed update is 65.5.1 -> 70.0.0, not just 65.5.0 -> 65.5.1 as it was there).

[tianon]

GHSA-cx63-2mw6-8hw5

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.

I think I'm understanding correctly that this is only a security issue if you're blindly trusting attacker-controlled URLs and asking for them to be installed? That seems to limit the spread/impact considerably, especially since setuptools being part of an actual application stack seems unlikely (it'd be much more likely to be used during image build for installing packages/dependencies).

[tianon]

pypa/setuptools@v65.5.1...v70.0.0 is frankly a huge amount of change, and I'm certainly not comfortable making the blanket decision that this aggressive of an update is "OK" for all users of these images.

(Again, see #781 (comment) for a longer-form explanation of where I [still] stand on this.)