How to fix CVE-2022-40897?

Trivy detects vulnerability CVE-2022-40897 in setuptools 58.1.0, and I need to update it to 65.5.1 to fix it.

However, I don’t require setuptools directly and I can’t find out where it’s required. I tried adding setuptools==65.5.1 to my requirements.txt but this didn’t solve the problem. How can I fix this?

This is my requirements.txt:

setuptools==65.5.1
requests==2.25.1
python-decouple==3.4
google-cloud-bigquery==2.14.0
confluent-kafka==1.7.0
pyyaml==5.4.1
requests==2.25.1
avro==1.11.0
fastavro==1.4.0
google-api-core==1.26.0
google-auth==1.30.0
googleapis-common-protos==1.52.0
google-cloud-logging==1.15.1
pytest==6.2.5
coverage==7.2.2

What does pip show setuptools display in the “Required-by” line?

What OS are you using?
Is this an OS with setuptools install from a package?
Is the OS using an old version of python?
I would do this to find where setuptools is installed in the file system:

python3 -c “import setuptools;print(setuptools)”

I suspect your package doesn’t require setuptools at runtime, but rather it’s a requirement for installation. You can pin the version used in your pyproject.toml file (i.e. the example here):

[build-system]
requires = ["setuptools >= 61.0"]
build-backend = "setuptools.build_meta"
2 Likes

The Required-by line is empty, and Location is /usr/local/lib/python3.9/site-packages

I’m using the python:3.9-bookworm Docker image as a base (Debian 12), since this project uses Python 3.9

That docker image has setuptools 58.1.0 installed in the system Python environment. That’s the one you probably need to upgrade - how you do so depends on how it got installed. I’m not a Linux expert, so I can’t tell if it was installed using an OS package or by some other means (such as sudo pip, which is not a recommended approach…) You’ll need to work out how it was installed, and upgrade it appropriately depending on that. Sorry that’s not very useful advice, but you’re talking about modifying OS-managed software, so the potential for breaking the environment is high, and I don’t want to advise you to do something dangerous if you don’t know what you’re doing…

One question I would ask - is this vulnerability report actually affecting you, or is the scanner simply detecting an outdated, but unused, copy of setuptools? If you’re careful to build using isolated virtual environments (either managing them manually, or relying on pip’s isolated build environments) then you may not even be using that copy of setuptools.

3 Likes

Thanks for the detailed answer. This is not actually affecting me, but our automated CI pipeline is blocking the resulting application image because of this CVE.

I’m almost sure we’re not using this copy of setuptools, so I guess our options are either to configure Trivy to ignore this particular vulnerability and/or report this issue upstream to the maintainers of the official Python Docker image.

For completeness sake, this is the Dockerfile we’re currently using. The pip install setuptools>=65.5.1 was added by me to try to fix this issue.

FROM python:3.9-bookworm as base

# Before Build Dependencies
ENV PYTHONUNBUFFERED=1

FROM base as builder
WORKDIR /app

RUN apt-get update && \
    apt-get upgrade && \
    apt-get install -y librdkafka-dev

COPY requirements.txt requirements.txt

RUN pip install --upgrade pip && \
    pip install setuptools>=65.5.1 && \
    pip install -r requirements.txt
COPY . .

FROM base as runner

COPY --from=builder /app /app
CMD ["python", "main.py"]

To be clear, the vulnerability is

Python Packaging Authority (PyPA) setuptools before 65.5.1 allows remote attackers to cause a denial of service via HTML in a crafted package or custom PackageIndex page. There is a Regular Expression Denial of Service (ReDoS) in package_index.py.

This shouldn’t be a problem here, because the entire point of the exercise is to control which packages are installed, and the ones in question are quite common dependencies. Actually, looking at the changes, I can’t see how a “crafted package” causes the problem; it appears to result from a private index potentially using weird <link rel=...> metadata on its index page.