Possible False Negatives on Amazon-Linux-Based Systems

[mattlorimor]

What would you like to be added:

Further hydration of AL vuln data using explore.alas.aws.amazon.com (or something better if Amazon maintains it).

Currently, for Amazon-Linux-based distributions, the ALAS Advisories seem to be the only thing parsed. This seems to result in situations where CVEs exist in system packages on Amazon Linux but do not surface up in scanners like Grype, Trivy, Wiz, etc. The crux of this is that Amazon does not seem to issue an ALAS Advisory unless a fix is also being released. However, the data for whether their distros/lineages are affected exists and seems to be consumable.

Why is this needed:

CVE scanners should strive to be as correct as possible with respect to which CVEs exist on any given system.

I tested all of this looking for this curl CVE on amazonlinux:2. Grype, Trivy, and Wiz all do not find it. This is all despite the fact that a vulnerable version does appear to be installed:

docker run -it amazonlinux@sha256:bccc33f13237edc45012bb061400858907dd21dfcfdb0fb803b5b34d333e6d20 /bin/bash
bash-4.2# curl --version
curl 8.3.0 (aarch64-koji-linux-gnu) libcurl/8.3.0 OpenSSL/1.0.2k-fips zlib/1.2.7 libidn2/2.3.0 libpsl/0.21.5 (+libidn2/2.3.0) libssh2/1.4.3 nghttp2/1.41.0 OpenLDAP/2.4.44
Release-Date: 2023-09-13
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe UnixSockets

Additional context:
It has always been my understanding that scanners are at the mercy of what ALAS (and other distro vuln databases) tell them. In this case, there certainly seems to be more data/signal that could be consumed and used to populate the Grype vuln db.

I'm curious whether this has ever been discussed and that not consuming the data surfaced at explore.alas.aws.amazon.com is a conscious choice that has been made.

[mattlorimor]

I'm assuming that there would be a potential problem when utilizing data from explore.alas.aws.amazon.com because Grype's entire trigger around building any vuln entry at all with respect to Amazon Linux is whether an ALAS advisory has been issued. It's almost like a db of CVEs should be being built up (and regularly rebuilt) based on the explore.alas.aws.amazon.com data that can be utilized. It's not great that there is a lack of info on the explore. page. Specifically, it doesn't list the Amazon Linux 1/2/2023 package version string that is affected. It simply lists whether that particular version of Amazon Linux is waiting on a fix, not affected, fixed, or some other status from the table listed here:

This all started when I saw that table in the FAQs because I knew that none of that status information was in the ALAS advisories. So, I wanted to know where it was. I didn't actually know about explore.alas.aws.amazon.com's existence until a few hours ago.

It's odd to me that scanners (I guess I can't ask you to speak for all scanners) would stop short after consuming ALAS data when the extra data saying whether a particular CVE affects AL, AL2, or AL2023 is right there. I just don't know how to marry the two data sets into something that can be turned into actual scan results.

[mattlorimor]

Related: anchore/grype#368

[willmurphyscode]

Thanks very much @mattlorimor! It sounds like there might be a better data feed to use then the one we currently use, which is at:

vunnel/src/vunnel/providers/amazon/parser.py

Lines 18 to 23 in c79b83a

	amazon_security_advisories = {
	# '1': 'https://alas.aws.amazon.com/alas.rss',
	"2": "https://alas.aws.amazon.com/AL2/alas.rss",
	"2022": "https://alas.aws.amazon.com/AL2022/alas.rss",
	"2023": "https://alas.aws.amazon.com/AL2023/alas.rss",
	}

I'll pick this up and start investigating. I really appreciate the issue.

[mattlorimor]

@willmurphyscode - Thanks for taking a peek!

the one we currently use, which is at

Right; the ALAS feeds. I'm hoping this other data can be used wholesale to make scanning more accurate. Or, if it can't, NVD can be considered again. My understanding of how scanning Alpine works is that it starts with NVD data, but will then do a pass taking into account the Alpine DB feed data, but I could be remembering incorrectly there. If correct, it'd be interesting if the Amazon Linux scanning could be altered to take a similar approach.

[mattlorimor]

For posterity (and for my own sanity), I tested out the aforementioned curl CVE on current AL2 and AL2023 (they're the only ones running affected versions). Both have the functionality as described by the CVE. Neither Grype, Trivy, nor Wiz detect that it's a vulnerable version (when it clearly is as proven by actually performing the "exploit").

[mattlorimor]

@willmurphyscode - Circling back to this. I just spot checked that same curl CVE again. I'm not thrilled with what I see in explore.alas.aws.amazon.com. That "feed" doesn't show it as fixed against AL2023, but a new container spun up off amazonlinux:2023 shows curl at 8.11.1. I'm not sure how up-to-date Amazon keeps that data set. This is extremely frustrating.