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.)

[johandebraak]

This is extremely annoying if you consider many companies are dealing with auomated security scans for SOC2 etc related stuff. Not sure if there is anything that can be done to be fixed other than building a custom image with setuptools>70 or ignoring this vuln on dockerhub

if you don't need setuptools once your image is built, you may uninstall it (i.e. include RUN pip uninstall setuptools -y near the end of the Dockerfile