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

[josumoreno-BP]

trafficstars

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 https://github.com/docker-library/python/issues/781#issuecomment-1372524712 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]

https://github.com/advisories/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]

https://github.com/pypa/setuptools/compare/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 https://github.com/docker-library/python/issues/781#issuecomment-1372524712 for a longer-form explanation of where I [still] stand on this.)

[aiakubovich]

Hello, I am getting the following vulnerability when trying to deploy via pipeline with aqua scan: https://security-tracker.debian.org/tracker/CVE-2024-6345 . I was trying to install other version via requirements.txt but it leads to the same vulnerability

[isidentical]

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

[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

[aiakubovich]

@isidentical

i found that docker images with python full of those vulnerabilities and it is pain to remove each of those. I suggest using simplified docker image. Some recommendations: https://github.com/GoogleContainerTools/distroless https://github.com/chainguard-dev https://github.com/wolfi-dev

[yosifkit]

Your options for getting an updated setuptools or clean scan (https://github.com/docker-library/python/issues/1012#issuecomment-2736331135):

You will either need to either:

1. Update to Python 3.12 or newer (which no longer bundles setuptools)
2. Update setuptools in your own Dockerfile
3. Ask upstream CPython to update to newer setuptools in Python 3.11
4. Suppress the vulnerability alert if appropriate (you didn't say what vulnerability you were referring to, but it's quite possible it's a non-issue in practice - many setuptools codepaths are not used when it's used as a pip build backend, or need several other criteria to be a problem etc)

---

Because of the extreme likelihood of a breaking changes, we no longer update setuptools in the python images; we just include the bundled version (or don't include it at all, as is the case with 3.12+). Again, see also https://github.com/docker-library/python/issues/781#issuecomment-1372524712 for a longer form explanation.