Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Outdated, fixed vulnerabilities are still being reported for new Debian packages #1556

Open
joell opened this issue Jan 31, 2025 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@joell
Copy link

joell commented Jan 31, 2025

Recently, osv-scanner has started reporting old, fixed vulnerabilities for new Debian packages.

Here is a quickly reproducible example using the openssl package from Debian 12:

$ osv-scanner --version
osv-scanner version: 1.9.2
commit: n/a
built at: n/a

$ cat >openssl.dpkg-status <<EOF
Package: openssl
Version: 3.0.15-1~deb12u1
Multi-Arch: foreign
Priority: optional
Section: utils
Maintainer: Debian OpenSSL Team <[email protected]>
Installed-Size: 2351 kB
Depends: libc6 (>= 2.34), libssl3 (>= 3.0.9)
Suggests: ca-certificates
Filename: pool/main/o/openssl/openssl_3.0.15-1~deb12u1_amd64.deb
MD5sum: 7f636f8970fcd68823c24ec3c9c3bd00
SHA256: c9c37660d902f2a43dfbbf619b3f5f413cee298d8f317829e3c11cfff9e174aa
Homepage: https://www.openssl.org/
Tag: implemented-in::c, interface::commandline, protocol::ssl, role::program,
 scope::utility, security::cryptography, security::integrity,
 use::checking
Download-Size: 1427 kB
APT-Sources: http://deb.debian.org/debian bookworm/main amd64 Packages
Description: Secure Sockets Layer toolkit - cryptographic utility
EOF

$ osv-scanner -L dpkg-status:openssl.dpkg-status
Scanned /home/hezekiah/work/didactic/fp/navajo/openssl.dpkg-status file as a dpkg-status and found 1 package
╭────────────────────────────────┬──────┬───────────┬─────────┬──────────────────┬─────────────────────╮
│ OSV URL                        │ CVSS │ ECOSYSTEM │ PACKAGE │ VERSION          │ SOURCE              │
├────────────────────────────────┼──────┼───────────┼─────────┼──────────────────┼─────────────────────┤
│ https://osv.dev/CVE-2023-6129  │ 6.5  │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2023-6237  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-0727  │ 5.5  │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-13176 │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-2511  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-4603  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-4741  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-5535  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-6119  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
│ https://osv.dev/CVE-2024-9143  │      │ Debian    │ openssl │ 3.0.15-1~deb12u1 │ openssl.dpkg-status │
╰────────────────────────────────┴──────┴───────────┴─────────┴──────────────────┴─────────────────────╯

Taking the first reported vulnerability, when looking up CVE-2023-6129 it shows that under Debian 12 this vulnerability was fixed in version 3.0.13-1~deb12u1. Since we are scanning on version 3.0.15-1~deb12u1 this vulnerability shouldn't apply. Yet it is still being reported.

@oliverchang
Copy link
Collaborator

Thank you for the report!

@hogo6002 can you please take a look at this?

@hogo6002
Copy link
Contributor

hogo6002 commented Feb 3, 2025

Hi @joell

CVE-2023-6129 has two Debian records: one for Debian:12 and one for Debian:13. Because we are querying the Debian ecossystem without specifying a release number (e.g. Debian:12), the query matches packages against all releases. In this case, Debian:13 has an affected range from 0 to 3.1.5-1, and the queried version 3.0.15-1~deb12u1 will be treated as vulnerable in this range (due to Debian version compare).

@hogo6002
Copy link
Contributor

hogo6002 commented Feb 3, 2025

Even if we hardcode the osv.dev side to only query against Debian:12 when the version string contains deb12, the issue will still exist if the queried version is a regular one without any release number in it.

@another-rex
Copy link
Collaborator

another-rex commented Feb 3, 2025

I think this issue might be fixed in osv-scanner v2, because when scanning dpkg-status, we also check the OS version in /etc/os-release. Of course this only works when scanning on a system with the correct /etc/os-release file. Can you test it out to see if that suits you?

We likely want to figure out a way for users to pass in the Debian/Alpine/Ubuntu... release versions when scanning OS package files.

@oliverchang
Copy link
Collaborator

I think this issue might be fixed in osv-scanner v2, because when scanning dpkg-status, we also check the OS version in /etc/os-release. Of course this only works when scanning on a system with the correct /etc/os-release file. Can you test it out to see if that suits you?

We likely want to figure out a way for users to pass in the Debian/Alpine/Ubuntu... release versions when scanning OS package files.

+1. Our first V2 beta is here: https://github.com/google/osv-scanner/releases/tag/v2.0.0-beta1

@joell
Copy link
Author

joell commented Feb 3, 2025

@another-rex: Yes, when I test with osv-scanner v2-beta1 running inside a Debian 12 container, it correctly outputs only CVE-2024-13176.

However, as you suspected the --lockfile option is kind of broken currently. It tries to read /etc/os-release on the scanning system to interpret the provided lockfile. My dev system is Arch Linux, and when I try to scan a Debian 12 dpkg-status file directly from my dev box (not from within a Debian container), it spits out:

error when retrieving vulns: client error: status="400 Bad Request" body={"code":3,"message":"Invalid ecosystem."}

Adding an option to accompany --lockfile that allows the user to specify the target OS would resolve this. (In fact, you might want to consider making it mandatory; scanning the host /etc/os-release is unexpected from this user's perspective, and would likely produce a lot of surprising errors and/or misleading results.)

@another-rex
Copy link
Collaborator

Good idea, created #1565 to track this feature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants