False positive CVEs reports for patched packages

[AMDmi3]

TL;DR: Some repository has some CVE patched, but Repology shows the package as vulnerable. This is known, and that's why Repology uses the term "potentially vulnerable". However there's no easy way to fix it right now.

• In either case, repositories should provide data on mitigated CVEs in a machine readable format which is not the case for e.g. DSA/GLSA
• We need to implement algorithm for each distro specific version comparison to know which internally used versions are not vulnerable. This is too huge work and is not planned right now.
• Alternatively, distros should tell us for every CVE which versions are not vulnerable. This is huge work on distros side instead
• Discussion is welcome

---

Sometimes when software is affected by vulnerability there's no new release in which it is fixed (yet), so distributions have to patch it instead of waiting for a new release. Also there are stable distributions which stick to older versions and patch them for CVEs and bugs instead of updating to a newer versions. In both cases there needs to be a way for distributions to convey that they are unaffected by specific CVEs.

Here are examples of existing tools:

• Debian security
• Gentoo security database
• FreeBSD vuxml

Unfortunately they all share the same property of relying on distro-specific version comparison algorithm in order to determine whether specific package version is vulnerable and in some cases lacking a machine readable form. For instance:

• Debian:

  For the stable distribution (buster), this problem has been fixed in version 3.27-6+deb10u1.

• Gentoo:

  Unaffected versions | >= 4.2.0-r5

• FreeBSD

  <vuln vid="88760f4d-8ef7-11ea-a66d-4b2ef158be83">
    <topic>mailman -- arbitrary content injection vulnerability via options or private archive login pages</topic>
    <affects>
      <package>
        <name>mailman</name>
        <range><lt>2.1.30_4</lt></range>
        <range><ge>2.1.31</ge><lt>2.1.33</lt></range>
      </package>

In all cases specific version algorithms are needed to be implemented in order to match these entries against packages to determine which of them are not affected by mentioned vulnerabilities. Repology supports 70+ repository families and it would be too huge task to implement version comparison algorithms for all of them. Additionally, we would like to encourage community to come with a common machine readable format of publishing information on vulnerability status to allow other (probably more security centric than Repology) tools to be introduced, without the need to reimplement this huge set of version comparison and parsing algorithms.

So, although I absolutely expect complaints from (especially stable) distros on false positive CVE linkages to their (patched) package, there's no way to fix it without their cooperation and I encourage a discussion.

[AMDmi3]

Some quick thoughts on the desired properties of a format usable for distro-agnostic information on patched vulnerabilities sharing:

• Commonly used machine-readable format as a base (JSON)
• Which describes a list of facts...
• ...of mitigating [a set of] vulnerabilities in [a set of] packages, with a reasonable amount of additional details
• Notably, package identifiers should be informative and flexible enough to precisely identify packages in an environment where multiple package types (source; binary for different architectures), multiple repositories and repository branches exist, not residing to a version comparison. It should also take into account that a vulnerable package and a fixed update for it may exist in different repositories (probably Debian case).
• Preferably, the format should (mandatory) reference a complete definition of a mitigation (e.g a patch), so the mitigation correctness could be audited and/or ported into another environment

Unfortunately it looks like the only way to precisely identify packages without version comparisons would be to list ALL exact names and versions verbatim which would require much work on distributions side (e.g. a distroy needs to track all package versions/revisions potentially affected by the vulnerability and list all of them), which may compare to implementing a lot of version comparison algs a considerable alternative.

Anyway, some examples somewhat modelled after the above mentioned cases.

{                                                                                                                                                                                                                                                                                                            
  "version": "1.0",
  "mitigations": [
    {
      "vulnerabilities": ["CVE-2020-11102", "CVE-2020-1711", "CVE-2020-7039"],
      "fixes": [
        {
          "type": "patch-tarball",
          "url": "https://dev.gentoo.org/~tamiko/distfiles/qemu-4.2.0-patches-r2.tar.xz"
        }
      ],
      "packages": [
        {
          "names": ["emulation/qemu"],
          "versions": ["4.2.0-r5", "4.2.0-r6", "4.2.0-r7", "4.2.0-r8", "4.2.0-r9", "4.2.0-r10"]
        }
      ]
    }
  ]
}

The simple case as we don't need to track binary repository separately. So here's a feed which lists a single fact of mitigation of 3 CVES by patchset in a form of tarball, and it marks the listed versions of package named emulation/qemu as fixed. Again note that each next ebuild revision would have to be appended to the list, up to a version not affected by the named CVEs.

---

{
  "version": "1.0",
  "mitigations": [
    {
      "vulnerabilities": ["CVE-2018-13796"],
      "fixes": [
        [
          {
            "type": "patch-raw",
            "url": "https://svn.freebsd.org/ports/head/mail/mailman/files/postfix-verp.diff"
          }
        ]
      ],
      "packages": [
        {
          "source": true,
          "names": ["mail/mailman"],
          "versions": ["2.1.30_4", "2.1.30_5", "2.1.30_6"]
        },
        {
          "source": false,
          "arch": "*",
          "names": ["mailman", "mailman-with-htdig"],
          "versions": ["2.1.30_4", "2.1.30_5", "2.1.30_6"]
        }
      ]
    }
  ]
}

A bit more interesting FreeBSD case which differentiates source and binary repositories because source and package names differ here.

---

{
  "version": "1.0",
  "mitigations": [
    {
      "vulnerabilities": ["CVE-2020-1763"],
      "fixes": [
        [
          {
            "type": "patch-description",
            "url": "https://salsa.debian.org/debian/libreswan/-/blob/CVE-2020-1763/debian/patches/0006-security-Fix-for-CVE-2020-1763.patch"
          },
          {
            "type": "patch-raw",
            "url": "https://salsa.debian.org/debian/libreswan/-/raw/CVE-2020-1763/debian/patches/0006-security-Fix-for-CVE-2020-1763.patch"
          }
        ]
      ],
      "packages": [
        {
          "repository": "buster",
          "section": "main",
          "source": true,
          "names": ["libreswan"],
          "versions": ["3.27-6+deb10u1", "3.27-6+deb10u2", "3.27-6+deb10u3"],
          "overriding": {
            "versions": ["3.27-6"]
          }
        },
        {
          "repository": "buster",
          "section": "main",
          "source": false,
          "names": ["libreswan", "libreswan-dev", "libreswan-doc"],
          "versions": ["3.27-6+deb10u1", "3.27-6+deb10u2", "3.27-6+deb10u3"],
          "overriding": {
            "versions": ["3.27-6"]
          }
        }
      ]
    }
  ]
}

A more elaborate case for Debian. First, it lists two alternative forms of a fix - as a web page and as a raw patch. Next, it lists more details on repository location, also differentiates source and binary packages, and additionally lists versions overridden by the named packages - that is, if libreswan 3.27-6 and 3.27-6+deb10u1 may coexist in the repository (for example, one comes from release repo and another from updates), it is not enough to know that the latter is fixed, but also that the former may be no longer considered as it's overridden by the fixed package for users. Note that this would not be the case for Gentoo where vulnerable and fixed ebuilds may coexist without overriding each other.

[hmh]

If you are not aware of https://security-tracker.debian.org, please take a look. I believe at least Fedora has something similar.

You will notice you can fetch the Debian security-tracker database at:
https://security-tracker.debian.org/tracker/data/json

Please don't scrap it too often, once a day should be enough.

[AMDmi3]

I was aware, but I've totally missed JSON file there, which seems to contain just what I need - facts that a certain vulnerability was fixed for specific package in specific distro version. That is directly usable without the need to implement distro-specific version comparison which takes revisions into account. Of course a specific parser would be needed, but at least now there is a starting point.

[Anton-Latukha]

Just wanted to tell that distribution CVEs/patch search is a major feature not present elsewhere.

Hope that you would be able to capitalize on it.