AMDmi3
commented
4 years ago 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
Anton-Latukha
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.
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:
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:
Gentoo:
FreeBSD
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.