Question on scope: Where should shared library vulnerabilities go?

[captn3m0]

Usually, audit tooling (such as pip audit, or grype) picks up dependencies, and checks them accordingly. However, in case of binary wheels in Python, packages can include (using manylinux/auditwheel or otherwise) shared libraries in the wheel. These are quite hard to trace back to the original distro package that they were copied from, and as a result, no tool (that I'm aware of) will mark the corresponding distro package in the SBOM.

As an example, see https://github.com/vinayak-mehta/pdftopng/issues/12, where pdftopng includes a vulnerable version of libpng, but that is not reported anywhere.

I was working towards detecting these issues automatically (https://github.com/pypa/auditwheel/issues/397), and was wondering what would be the right place to document these so Python audit tooling (such as pip-audit) picks them up. I can imagine two scenarios:

1. Generating SBOMs for each of the vulnerable wheels to include the distro package versions. Perhaps auditwheel could include this in the metadata going forward, or having a separate tool for now that audits a wheel and provides a SBOM including this information. This second-level SBOM can then be used by other (mostly non-python) tooling to detect any vulnerabilities. However, tooling such as pip-audit will need to be updated.
2. Publish this information in the advisory database (or GHSA), so it gets immediately used everywhere, at the cost of duplicating the vulnerability (The CVE is really in an upstream package, but wheels are bundling those).

[di]

Great question, thanks for filing an issue.

I think you're right, we need a standard way to declare 'vendored' dependencies inside of wheels, (likely with SBOMs). Myself and some other folks are drafting a PEP for this, I'll ask them to comment here as well.

Ideally, then, audit tooling will be able to pick up on the presence of a 'vulnerable' sub-dependency within a distribution. However, this means that auditing tooling will need a way to relate the installed project name to the SBOM, which might not be available in all environments.

For now, I think a stopgap solution would be to do your second suggestion, as I do think the presence of a vulnerable vendored dependency should be grounds for generating a CVE against the parent project as well.

[captn3m0]

I filed https://github.com/pypa/auditwheel/issues/398 for the "declaring censored SBOM" problem.

I'm not sure if auditwheel is the right layer to solve it at, but it will definitely need to be part of the solution, seeing as the majority of such packages are using it.

[captn3m0]

Will file an issue/PR for (2) here when I make some progress.

[di]

I definitely think auditwheel will need to support updating/amending the SBOM when repairing a wheel, but I think there's upstream tooling like build which should also provide a way to generate an SBOM or SBOM-like thing when dependencies are being vendored into the distribution.

[sethmlarson]

I think you're right, we need a standard way to declare 'vendored' dependencies inside of wheels, (likely with SBOMs). Myself and some other folks are drafting a PEP for this, I'll ask them to comment here as well.

Hey @di, is this draft PEP available anywhere I can contribute to?

[di]

@sethmlarson Yes: https://github.com/di/peps/pull/3, although it's a bit stalled (cc @teruokun)

[sethmlarson]

I have some more clarity here after speaking with MITRE. For vulnerabilities which are affecting a piece of software which is bundled along with the rest of the distribution of a project (either in its entirety or as a copy-pasted piece of code) there must be only one CVE ID assigned for that vulnerability, even if it affects multiple projects.

I proposed using a separate OSV advisory which references the original CVE and they said this was fine to do. So from my understanding the above would be this process:

• Update the bundled shared library to a non-vulnerable version. Make a release
• Mention in the changelog or elsewhere that the bundled shared library not being safe due to CVE-202X-XYZ.
• Create an advisory here in pypa/advisory-database with the proper affected versions.

I had some follow-up which I'm asking in the OSSF Vuln Disclosures WG on Slack:

• Would using the aliases field for the original CVE ID be appropriate, or only a reference. I believe in this case it should only be a reference since the affected product is completely different. Separate action needs to be taken to resolve the issue.

[sethmlarson]

I've created an advisory PR for the shared library libwebp.so that is included with imagecodecs according to what I mentioned above. If this seems good to folks, I think we can codify it in CONTRIBUTING.md.

[oliverchang]

I've created an advisory PR for the shared library libwebp.so that is included with imagecodecs according to what I mentioned above. If this seems good to folks, I think we can codify it in CONTRIBUTING.md.

Thanks for doing that! Big +1 to doing this generally when the vulnerable dependency is bundled. related seems like the more correct field to use for the CVE IDs in most of these cases.

[captn3m0]

Thanks a lot for the advisory, this is helpful.

I think the questions raised in this issue have been well answered now, so we can close this now.