false positive - python-setuptools

[faust64]

Description

A while ago, I pinged RedHat support, regarding some python-setuptools vunerability spotted by Trivy.
Since then, support got back to me and confirmed the fix was now avaialable.

Yet trivy keeps reporting about that vulnerability:

class: lang-pkgs
type; python-pkg
vulnerability:
  ID: CVE-2022-40897
  PkgName: setuptools
  PkgPath: /opt/app-root/kube/python3.9/site-packages/setuptools-53.0.0.dist-info/METADATA
  InstalledVersion: 53.0.0
  FixedVersion: 65.5.1
  ...
  Descripition: Python Packaging Authority (PyPA_ setuptools before 65.5.1 allows remote attackers to cause a denial of service .......

For the record, RedHat advertises ( access.redhat.com/errata/RHSA-2023:0952 ) that the fix ships in python3-setuptools-53.0.0-10.el9_11.noarch.rpm.

I think this may be a false positive. Given Trivy seems certain the only fix would be to upgrade to 65.5.1 ...
Am I doing it wrong? Should I wipe the cache of my trivy container and try again (db looks up to date/just upgraded yesterday, in doubt)?

Those scans have been marked as failing for over a month, since RedHat came through and told me they shipped their own fix.

What did you expect to happen?

Building an image from ubi9/python39. With few dependencies (kopf/kubernetes libs). I would expect my scans to find 0 vulnerablities.
According to RH container registry, there shouldn't be any known vulnerability here: https://catalog.redhat.com/software/containers/ubi9/python-39/61a61032bfd4a5234d59629e?tag=1-114.1681379027&push_date=1681409110000

What happened instead?

Scan keeps reporting 1 vulnerability. RedHat insists it's no longer vulnerable.
Who should I trust?

Output of run with -debug:

can't share this / don't have access to GitHub from the workstation I use operating my customer's clusters.
details about vulnerability shared above.
still persists as of today, using redhat's latest image (released yesterday evening)

Output of trivy -v:

(from my trivy server / scans would be running on clients with no persistent volume attached)

Version: 0.39.1
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-04-14 06:09:41:... UTC
  NextUpdate: 2023-04-14 12:09:41... UTC
  DownloadedAt: 2023-04-14 06:39:27... UTC

Additional details (base image name, container registry info...):

N/A

[DmitriyLewen]

Hello @faust64
Thanks for your report!

We investigated this image(registry.access.redhat.com/ubi9/python-39:1-114.1681379027) and found strange case:
Image contains 2 folder with setuptools:

(app-root) sh-5.1$ find . -name "setuptools-53.0.0.dist-info"
./usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info
./opt/app-root/lib/python3.9/site-packages/setuptools-53.0.0.dist-info

RPM only has information for /usr/... folder:

(app-root) sh-5.1$ rpm -ql python3-setuptools | grep setuptools-53.0.0.dist-info
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/INSTALLER
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/LICENSE
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/METADATA
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/RECORD
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/REQUESTED
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/WHEEL
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/dependency_links.txt
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/entry_points.txt
/usr/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/top_level.txt

(app-root) sh-5.1$ rpm -q --whatprovides /opt/app-root/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/METADATA 
file /opt/app-root/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/METADATA is not owned by any package

It looks like python3.9/site-packages/setuptools-53.0.0.dist-info folder was just copied in /opt/app-root or something like that.

That is why we can't exclude /opt/app-root/lib/python3.9/site-packages/setuptools-53.0.0.dist-info/METADATA from result as system file and Trivy finds vulnerabilities from GitHub/GitLab databases(these databases are not aware of the RedHad patches for this package).

RedHat came through and told me they shipped their own fix.

Perhaps you can ask RedHat about this strange case? How was this package installed in the opt/... folder?

Best Regards, Dmitriy

UPD:
I also checked registry.access.redhat.com/ubi9/ubi:9.1.0-1817 image with preinstalled setuptools. This image only has usr/... folder.

UPD2:
Perhaps package from opt... installed with pip. In this case Trivy works correctly

[faust64]

Hi,

Thanks for the quick reply, @DmitriyLewen

Indeed you're right, there are two versions of that setuptools module, in python3.9/ubi9 base image provided by RedHat
Once upon a time, sources for S2I base images shipping with openshift were all available, in several "sclorg" repositories, in GitHub.
For python, today, I find the following: https://github.com/sclorg/s2i-python-container/tree/master/3.9

Now ... lacking any better idea ... let's dig in ...
From that ubi9/python3.9 image. Say I extract the content of /usr/lib/python3.9/site-packages/setuptools AND /opt/app-root/lib/python3.9/site-packages/setuptools.
Diffing both folders, we see a lot of "pathA/fileX.pyc and pathB/fileX.pyc differ" ... not much worried about those ones ... let's find pathA pathB -name "*.pyc" -delete. Next diff: it's a match. The python files shipping with that setuptools we can find in /opt/app-root are the exact same as those we have in /usr/lib.

Now, let's check RH didn't lie to me when suggesting they fixed it, on a 53.0.0.
Digging through the reports ... I find that issue: pypa/setuptools#3659 which got closed by the following commit: pypa/setuptools@43a9c9b
Then, we can see the fix involves the following diff:

[in setuptools/package_index.py, circal line 220]
- REL = re.compile(r"""<([^>]*\srel\s*=\s*['"]?([^'">]+)[^>]*)>""", re.I)
+ REL = re.compile(r"""<([^>]*\srel\s{0,10}=\s{0,10}['"]?([^'" >]+)[^>]*)>""", re.I)

Checking the code i find in my ubi9/python3.9 image ... I can confirm we can see the new regexpr is there.
And checking /opt/app-root ... we can confirm as well: fix is there too.
While looking at the dockerfiles ... I'm not sure I completely follow everything, but that /opt/app-root seems to be setup as a virtualenv.

Although I'm not sure I can explain exactly how RH builds those ... I'm pretty sure today: this is a false positive.
Now for sure ... fixing scripts without publishing them as a new version into upstream, ... I have no words ... for how stupid and counter-productive this is ... on brand. for RH.

[DmitriyLewen]

Hello @faust64
Thanks for this investigation.
It is really strange case.

And checking /opt/app-root ... we can confirm as well: fix is there too.

Looks like currently only one way is skip /opt/app-root dir.

[github-actions]

This issue is stale because it has been labeled with inactivity.

[jamespack]

I believe in my case it was coming from the base image. For anybody that may end up here in the future looking for answers.

https://hub.docker.com/layers/library/python/3.9-alpine/images/sha256-7e53de21917d6793787bc67483838360404bb2fd70d9c3e38ccc243790c323b2