Bug 880521 – GLSA announcements show non-vulnerable versions of packages as affected

• Product: Websites
• Status: CONFIRMED ---

[Description cmwatts 2022-11-08 21:27:59 UTC]

See for example GLSA 202211-01. The vulnerability noted is for openssl >=3.0.0 and <3.0.7. But the 'Affected versions' says '< 3.0.7' and 'Unaffected versions' says '>= 3.0.7'. This can cause Tenable (for example) to build a plugin that marks any openssl (in this instance) less than 3.0.7 as vulnerable, even though the current stable version is 1.1.1q and is unaffected by the underlying vulnerabilities that generated the GLSA in question.

Desired result would be for the GLSA to state the vulnerable version(s) of a package. For example, this vulnerability could say:

Affected Versions - >3.0.0 <3.0.7
Unaffected Versions - <3.0.0 >=3.0.7

From what I've been able to gather, this would involve a change in the parsing of the XML that generates the web page to consider the slot(s) involved and only list those pertaining to the vulnerable slots as Affected and/or list those not pertaining to the slots involved as Unaffected.

Reproducible: Sometimes

Steps to Reproduce:
Only happens when a GLSA is published against a slot that contains vulnerable versions and where the situation is that there are earlier slots that contain package versions that are not vulnerable, from what I understand.
Actual Results:  
Affected versions < 3.0.7
Unaffected versions >= 3.0.7

Expected Results:  
Desired results as in the description:

Affected Versions - >3.0.0 <3.0.7
Unaffected Versions - <3.0.0 >=3.0.7

Considering this an enhancement request, but a potentially important one so that the GLSA can better align with reported vulnerabilities, especially as relates to third-party vulnerability management/scanning tools.

[Comment 1 John Helmert III 2022-11-08 21:39:59 UTC]

Specifically, this is about the page here:

https://security.gentoo.org/glsa/202211-01

If anyone is relying on the GLSA page at security.gentoo.org as an authoritative source of truth for GLSA content, I'd say that's a bug in itself.

The range of affected packages is explicit in the GLSA XML itself (https://gitweb.gentoo.org/data/glsa.git/tree/glsa-202211-01.xml#n13):

<unaffected range="ge" slot="0/3">3.0.7</unaffected>
<vulnerable range="lt" slot="0/3">3.0.7</vulnerable>

That slot is only held by versions of Openssl-3, so the GLSA does indeed accurately target the right versions. Going to reassign this bug as a websites issue.

[Comment 2 cmwatts 2022-11-08 22:09:11 UTC]

Thank you. I am looking at the NASL for Tenable/Nessus plugin 166788 (gentoo_GLSA-202211-01.nasl). It appears they got it 'right' on this one, as it contains an 'unaffected' list of "ge 3.0.7", "lt 3.0.0".

This behavior by Tenable was last seen with respect to this GLSA:

https://security.gentoo.org/glsa/202004-10

It was a similar situation where 1.1.1g was required for openssl if you were running 1.1.1d-1.1.1f versions of openssl, but openssl 1.0.2x and 1.1.1a-c were unaffected at that time, which (unless Tenable has changed their methodology) makes me suspect that they are just reading the web page and building their Gentoo-related plugins, as opposed to consuming the XML and understanding slotting.

At the time, we opened a ticket with Tenable, and they claimed that Gentoo had said 'less than 1.1.1g is vulnerable', so they were going with what the vendor web page said, which made me suspect that they did not understand the non-vulnerable versions prior to 1.1.1g at that time.

I don't disagree that Tenable should read the XML and understand the slotting to evaluate vulnerabilities. And maybe they are now based on this current GLSA and its corresponding plugin source - or maybe the publicity around this bug stimulated them to do the 'right thing' just in this particular instance. It's hard to say as I lack visibility into their internal processes for building Gentoo-specific plugins.

I also think it would be better if the web page were accurate in terms of humans consuming this information as a general point and would still mitigate potential future issues with scan vendors. I.e.: My opinion, for what it's worth, is that having the web page versions of GLSA clearly specify vulnerable package versions would be a net positive.

[Comment 3 John Helmert III 2022-11-09 02:49:21 UTC]

In the case of GLSA-202004-10, Tenable is right, we do mark <1.1.1g as vulnerable. As I recall, that GLSA was pushed through by Whissi (now retired) without any review, which shouldn't happen anymore.

In any case, openssl versions <1.1.1 are masked now, so there's no reason to touch the GLSA at this point.

[Comment 4 John Helmert III 2022-11-09 02:50:26 UTC]

(of course, that's orthogonal to the UI issue of the website, that is indeed a valid issue)

[Comment 5 cmwatts 2022-11-09 14:47:39 UTC]

Thank you for that clarification. Will look forward to feedback as far as whether we can get the website to match the slotting so as to increase accuracy from a UI perspective, as we are hoping for.