Thread by @lorenc_dan

It's been awhile, so let's do another CVE Deep Dive! This time, let's look at CVE-2022-46908, a critical vulnerability in sqlite! This currently shows up in all three scanners tested (snyk, trivy, and grype) against the GCP Distroless Python 3 image.

Looking in the NVD, we can see that this is a sanitization bug in the "safe" mode of operating sqlite, where some unsafe functions are still allowed to be called: nvd.nist.gov/vuln/detail/CV…

The affected versions range shows that every version of sqlite is affected, including the latest version (3.40.0)! This means the upstream project has not issued a release with the fix, which can slow down distros receiving patches.

Jumping to the Debian issue tracker however, we can see that the Debian developers have marked most releases as fixed, which could mean they back-ported the fix manually or decided it was not applicable in their configuration.

To tell the difference, we need to look into the Debian bug to see: bugs.debian.org/cgi-bin/bugrep…

We can see that in here, they actually noticed the vulnerable function was not introduced until 3.37, so it's not present at all in most of the Debian builds:

bugs.debian.org/cgi-bin/bugrep…

This looks like a case where the NVD is incorrect, which happens more often than it should. Typically the security scanners would notice that Debian has marked this as fixed and reflect it in the scanner output.

This might just be delay.

This is also a great use case for VEX: chainguard.dev/unchained/putt…

Even if the vulnerability is present in sqlite, it requires specific functionality to be used (user defined functions with unsafe inputs).

A VEX entry could be published if the vulnerable code is not called.

This is also a case where scanners are likely to miss some instances due to "dark files": chainguard.dev/unchained/soft…

Sqlite is commonly embedded in other apps, making it hard for SCA-based tools to identify. Accurate, build-time SBOMs would be needed to find this 100% of the time.