On 07/11 10:22, Noah Meyerhans wrote: > [...] These two OVAL definitions list essentially identical criteria, > yet their actual status in bullseye is quite different: > > CVE-2020-28200 is still present in bullseye and is a legitimate > finding by any scanner based on these definitions: > https://security-tracker.debian.org/tracker/CVE-2020-28200 > > CVE-2012-0833 is not present in any bullseye and should not trigger a > finding from a scanner: > https://security-tracker.debian.org/tracker/CVE-2012-0833 > > If we look at the security-tracker's JSON feed [2], we see some > details that should be reflected in the OVAL feed but aren't, in > particular the "status" field: > > "CVE-2012-0833": { ... > "releases": { ... > "bullseye": { "status": "resolved", "repositories": { > "bullseye": "1.4.4.11-2" }, "fixed_version": "0", "urgency": > "unimportant" > }, ... } and > > "CVE-2020-28200": { > "releases": { ... > "bullseye": { "status": "open", "repositories": { "bullseye": > "1:2.3.13+dfsg1-2" }, "urgency": "not yet assigned" > }, ... }, > > I'm not super familiar with the semantic expectations of OVAL, but I > think logically we want to represent CVE-2012-0833 somewhat > differently in OVAL using logic similar to: > > if status == resolved: if fixed_version == 0: > # All versions of this package in this release's repos are fixed: > OVAL_criterion = "package is earlier than > min(values.repositories)" > else OVAL_criterion = "package is earlier than fixed_version" > > In this case the criterion for CVE-2012-0833 would be: > > <criterion comment="389-ds-base DPKG is earlier than 1.4.4.11-2" > test_ref="oval:org.debian.oval:tst:4696"/> > > Which I believe is correct. If a system is running bullseye and has > 1.4.4.11-2 or later installed, then a scanner should determine that > this vulnerability is not present.
Thanks for the detailed report. I agree the current "greater than 0" criterion in OVAL isn't right, and ideally the JSON export would correctly list "min(version for version in all_versions_ever_in(repository)" in fixed_version instead of the current "0": the current OVAL code would then expose the correct result automatically. I'm not sure how feasible that is, as I'm not familiar with the JSON export code, but what I would *most* like to avoid here, is having that min() computation be performed on the OVAL side: it doesn't belong there, IMO. The other approach is for the OVAL code to simply skip a CVE entirely if the target distribution was never affected: it would remove the current false positives, and the only downside would be the lack of an alert is someone was to accidentally downgrade or hang on to a vulnerable version (from a previous stable suite for instance). I'm not sure if our OVAL exports should really for such a scenario, so maybe that's the better option here. Cheers, -- Seb
