Dan Lorenc Profile picture
Dec 18 8 tweets 4 min read
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:

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.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Dan Lorenc

Dan Lorenc Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @lorenc_dan

Sep 28
Today, the Senate will discuss and mark up the Today, the Senate will discuss and mark up the "Securing Open Source Act".

Lots has been said about it already, here's my take!



The gov. needs to get involved here, but a better would be "Securing the Usage of Open Source Act", because you can't secure OSS itself.

Open source is free expression, and it comes with no warranties. Securing/regulating it would be the same as regulating free speech.
But we do need change as an industry. I often hear the analogy that OSS is a "tragedy of the commons", and we just need to fix the economics and make corporations give back.

This is a popular take, but a lazy one and an incorrect one.
Read 8 tweets
Sep 10
New PCI Guidance for Containerized Environments just dropped! See @raesene's post for a more detailed look: raesene.github.io/blog/2022/09/1…

Here's a 🧵on the supply chain security, parts!
The doc is pretty short actually and the tables take up a lot of content, you should read the entire thing: raesene.github.io/blog/2022/09/1…

Sections 1&2 are background, and contain info on when not to use containers. This part is pretty funny:
Section 3 is the meat of the document, and outlines specific threats and mitigations/controls for them.

Section 3 in the table gets into workload security, where container signing and inventory makes the first appearance. No pulling by tags, and sign your containers!
Read 9 tweets
Sep 3
Here's the next installment in the CVE Tales Series!

Last week we talked about false negatives, let's bring back some (false) positivity with CVE-2008-1688, which shows up today in all 3 scanners (snyk, grype, trivy) in the official node image.

This CVE is over 14 years old, and was first filed in April of 2008, so how is it still showing up in our latest Node.js images?

Looking at the NVD data page, the description is a bit... sparse and confusing. There might be arbitary code execution!
The affected package is m4, the GNU macro preprocessor. If you're not familiar with it, the documentation page is humorous and worth the read. My favorite part:

"Beware that m4 may be dangerous for the health of compulsive programmers."

Read 10 tweets
Aug 28
CVE deep dive!

Today I'll look at how scanners work rather than a CVE.

I'll focus on how they find packages, because that's the first step in looking for CVEs.

I'll show a blind spot scanners have with many popular docker images, and how you might be missing a LOT of vulns.
As a test image, we'll use the node from DockerHub, and the syft tool to inspect it!

The syft tool can dump out the list of packages from an image, so lets run it on node to see what's inside.

The full output is here: gist.github.com/dlorenc/2128d2…
We can see a long list of packages of type deb and npm, because we find both OS and application level packages.

Something seems to be missing here though... Nodejs itself!

Since this is a debian image, we'd expect to see that as a .deb package. And in fact, it's not here.
Read 10 tweets
Jul 17
Everyone has heard of @kubernetesio, but few understand the power.

Here are 137 lines you can't run a container without!
apiVersion: apps/v1
kind: Deployment
Read 7 tweets
Dec 12, 2021
Funding OSS is a hot topic today! I got to spend a lot of time over the last two years working on paying OSS maintainers at @Google.

We spent a few million dollars and funded some relatively high profile work, in addition to a lot of smaller projects.

A 🧵on problems I saw!
This is going to sound blunt, but it's a distribution problem not a funding problem. $ is easy.

Corporations have budget and are willing to spend, but it takes too much time. Finding projects that need help and maintainers willing to help in exchange for money is hard.
OSS is mostly done by volunteers, but volunteer != unpaid.

Many projects are maintained by people that have jobs they're happy with, and these jobs allow them to spend some time on open source.
Read 10 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!


0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy


3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!