Open kmoens opened 2 years ago
The complete fix, with unit test, is on my fork in a branch already: https://github.com/kmoens/dependency-track/tree/bug/ubuntu-versions
I can create a merge request if wanted.
Thanks for the investigation work. Likely there will be many more cases, both debian and other distros, that will need to be accounted for over time. However, I think this is a good start.
I've incorporated your proposed change along with syncing with the upstream class it was originally derived from.
Hi,
I came to very similar issue related to SBom uploaded ubuntu docker image with openssl inside. Component details:
openssl
1.1.1f-1ubuntu2.11
pkg:deb/ubuntu/openssl@1.1.1f-1ubuntu2.11?arch=amd64&distro=ubuntu-20.04
cpe:2.3:a:openssl:openssl:1.1.1f-1ubuntu2.11:*:*:*:*:*:*:*
Dependency Track reports following vulnerability: https://nvd.nist.gov/vuln/detail/CVE-2021-3711 In Dependency Track vulnerability description is:
Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k).
However Ubuntu has this issue already fixed: https://ubuntu.com/security/CVE-2021-3711
focal Released (1.1.1f-1ubuntu2.8)
It seems, that in Ubuntu LTS version pattern the vulnerability will be forever reported as existing (unless Ubuntu uses full new version of openssl higher than 1.1.1l). Or must be suppressed manually.
Is there any way, how to solve this systematically? Probably some feature for importing also some CVE/CPE lists for e.g. Ubuntu?
Thanks.
Theoretically, if DT supported Ubuntu Security Noticies (USN) directly, rather than relying on CPE, this would be solvable. Ubuntu provides an OVAL feed, which is designed to assess a system. However, the SBOM would already have the package information defined in it, so I think using their OVAL feed to evaluate Ubuntu packages should work.
https://security-metadata.canonical.com/oval/
RedHat also provides OVAL along with CSRF (possibly CSAF 2.0 in the future), so adding proper support for security advisories specific to Linux distros along with information about the vulnerable packages could work using only the coordinates and/or purl defined in the bom.
Hi @stevespringett,
thanks for comment. Your idea sounds well, I had something like this in mind. Maybe it is more standalone enhancement of feature rather than bug. Thanks for considering this.
Can we make this also work with Debian (as opposed to just Ubuntu) packages? For example, in the case of openssl
above, you might have the version string 1.1.1n-0+deb11u3
to parse.
A very naive option might be to generalize the above regex to something like ^([0-9]+:)?(.*)(-[^-]+(ubuntu|deb)[^-]+)$
, but there may be smarter options!
Good to find this issue, which also affects me. It's a show stopper for me auditing container images based on Debian and Alpine. Even correctly detected versions result in false positives, e.g. openssl 1.1.1n-0+deb11u3 has backported fixes for most CVEs which affect 1.1.1n, but dtrack lists them as unfixed vulnerabilities.
Maybe looking at how Grype solved this issue could help:
They integrate reports/sources from the most popular distro into their database: https://github.com/anchore/grype#grypes-database There are particular version_constraints for each linux distribution/release. For any CVE id in their vulnerability table, they have corresponding entries for the distro/release and a flag if the issue is fixed
sqlite> .schema vulnerability
CREATE TABLE `vulnerability` (
`pk` integer,
`id` text,
`package_name` text,
`namespace` text,
`version_constraint` text,
`version_format` text,
`cpes` text DEFAULT null,
`related_vulnerabilities` text DEFAULT null,
`fixed_in_versions` text DEFAULT null,
`fix_state` text,
`advisories` text DEFAULT null,
PRIMARY KEY (`pk`)
);
sqlite> SELECT * FROM vulnerability WHERE id='CVE-2019-1543' AND namespace LIKE '%[ubuntu](ubuntu:19.04)%';
1503117|CVE-2019-1543|openssl|ubuntu:distro:ubuntu:19.04|< 1.1.1b-1ubuntu2.2|dpkg||[{"id":"CVE-2019-1543","namespace":"nvd:cpe"}]|["1.1.1b-1ubuntu2.2"]|fixed|
Ubuntu 22.04 with current ruby package (ruby 1:3.0~exp1
) results in 32 open CVE. However, all those CVE have been fixed in 22.04.
The leading 1:
in the version seems to confuse the version parser
Can we make this also work with Debian (as opposed to just Ubuntu) packages? For example, in the case of
openssl
above, you might have the version string1.1.1n-0+deb11u3
to parse.A very naive option might be to generalize the above regex to something like
^([0-9]+:)?(.*)(-[^-]+(ubuntu|deb)[^-]+)$
, but there may be smarter options!
Regarding Debian packages 1.1.1n-0+deb11u3
does not corresponds at all to upstream 1.1.1n
, many additional patches have been applied as mentioned by @muellerst-hg.
No regexp can solve this. Unsure if there is any easy fix. Some integration with debian security-tracker might be required...
This is unfortunatly still an issue for us. Any recommendations on how to handle it? We are currently marking those findings as false positives. But this task is very hard to do for all of those findings.
Current Behavior:
We have a cycloneDX BOM file, as generated by syft for our Docker containers. These Docker containers contain the OpenSSL library.
This is contained in the BOM file as follows:
When this BOM is uploaded, we get a number of vulnerabilities reported, including CVE-2019-1543. This CVE is stated on NVD as: "Fixed in OpenSSL 1.1.1c (Affected 1.1.1-1.1.1b). Fixed in OpenSSL 1.1.0k (Affected 1.1.0-1.1.0j).",
Similarly we found this info in the database as follows:
However, still dependency track reports that the OpenSSL 1.1.1f-1ubuntu2.4 is vulnerable against this CVE. Judging from the info dependency track has, it should not mark this one as a vulnerability.
Steps to Reproduce:
OR:
Expected Behavior:
Environment:
Additional Details:
After inspection of the code, I suspect that the
ComponentVersion
is the culprit here.If it parses the version
1.1.1f
it extracts[ '1', '1', '1f' ]
, while if we give it the version1.1.1f-1ubuntu2.4
it will extract['1', '1', '1', '1', 'ubuntu2', '10']
which is incorrect.I have a dirty patch for parsing the
ComponentVersion
as follows, but I did not submit it as a merge request yet since I'm not sure if it handles all cases correctly: