openssl - ubuntu package - versions not matched correctly

[kmoens]

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:

    <component type="library">
      <publisher>Ubuntu Developers &lt;[email protected]&gt;</publisher>
      <name>openssl</name>
      <version>1.1.1f-1ubuntu2.4</version>
      <cpe>cpe:2.3:a:openssl:openssl:1.1.1f-1ubuntu2.4:*:*:*:*:*:*:*</cpe>
      <purl>pkg:deb/ubuntu/[email protected]?arch=amd64</purl>
      <properties>
        <property name="foundBy">dpkgdb-cataloger</property>
        <property name="type">deb</property>
        <property name="metadataType">DpkgMetadata</property>
        <property name="path">/var/lib/dpkg/status</property>
        <property name="layerID">sha256:5a1aaa0fc304f17de4904b251554ad1d18d210122a495f40a726418f101018ec</property>
        <property name="path">/var/lib/dpkg/info/openssl.md5sums</property>
        <property name="layerID">sha256:d0af6cd0417d041e4be905c5344ff2d88c58294fd7e1eba1fc19d8dba795e1d3</property>
        <property name="path">/var/lib/dpkg/info/openssl.conffiles</property>
        <property name="layerID">sha256:d0af6cd0417d041e4be905c5344ff2d88c58294fd7e1eba1fc19d8dba795e1d3</property>
        <property name="path">/usr/share/doc/libssl1.1/copyright</property>
        <property name="layerID">sha256:d0af6cd0417d041e4be905c5344ff2d88c58294fd7e1eba1fc19d8dba795e1d3</property>
        <property name="installedSize">1257</property>
      </properties>
    </component>

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:

dtrack=# select "CPE23", "VERSION", "VERSIONENDEXCLUDING", "VERSIONENDINCLUDING", "VERSIONSTARTEXCLUDING", "VERSIONSTARTINCLUDING", "VULNERABLE" from "VULNERABLESOFTWARE" where "ID" in (select "VULNERABLESOFTWARE_ID" from "VULNERABLESOFTWARE_VULNERABILITIES" where "VULNERABILITY_ID" = 133548);
 cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* | *       |                     | 1.1.0j              |                       | 1.1.0                 | t
 cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:* | *       |                     | 1.1.1b              |                       | 1.1.1                 | t

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:

• Upload a cycloneDX BOM, containing the fragment above towards dependency track.

OR:

• Use syft to generate a CycloneDX BOM of the Ubuntu Docker image and upload that one towards dependency track.

Expected Behavior:

• Dependency Track does not report this one as a vulnerability.

Environment:

• Dependency-Track Version: 4.3.6
• Distribution: Docker
• BOM Format & Version: XML & JSON v1.3
• Database Server: PostgreSQL
• Browser: Chrome

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 version 1.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:

    public final void parseVersion(String version) {
        // handle deb versions
        String theVersion = version.toLowerCase();

        final Pattern debrx = Pattern.compile("^([0-9]+:)?(.*)(-[^-]+ubuntu[^-]+)$");
        final Matcher debmatcher = debrx.matcher(theVersion);
        if (debmatcher.matches()) {
            theVersion = debmatcher.group(2);
        }

        versionParts = new ArrayList<>();
        if (version != null) {
            final Pattern rx = Pattern.compile("(\\d+[a-z]{1,3}$|[a-z]+\\d+|\\d+|(release|beta|alpha)$)");
            final Matcher matcher = rx.matcher(theVersion);
            while (matcher.find()) {
                versionParts.add(matcher.group());
            }
            if (versionParts.isEmpty()) {
                versionParts.add(version);
            }
        }
    }

[kmoens]

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.

[stevespringett]

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.

[mkozina-gk-software]

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/[email protected]?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.

[stevespringett]

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.

[mkozina-gk-software]

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.

[carlturnerfs]

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!

[muellerst-hg]

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|

[muellerst-hg]

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

[mulder999]

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!

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...

[timosur]

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.