8000 false negative for cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:* · Issue #2365 · anchore/grype · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

false negative for cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:* #2365

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.

Sign up for GitHub

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

Jump to bottom
Open
jurassicLizard opened this issue Jan 8, 2025 · 14 comments
Open

false negative for cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:* #2365

jurassicLizard opened this issue Jan 8, 2025 · 14 comments
Assignees
@wagoodman
Labels
bug Something isn't working

Comments

@jurassicLizard
Copy link

What happened:

expected to find vulnerabilities for given cpe : cpe:2.3:o:linux:linux_kernel:6.6.16:::::::* but none were found

What you expected to happen:

expected to receive a list of vulnerabilities that exceed a 1000 for the given cpe cpe:2.3:o:linux:linux_kernel:6.6.16:::::::*

https://nvd.nist.gov/vuln/search/results?adv_search=true&isCpeNameSearch=true&query=cpe%3A2.3%3Ao%3Alinux%3Alinux_kernel%3A6.6.16%3A*%3A*%3A*%3A*%3A*%3A*%3A*

How to reproduce it (as minimally and precisely as possible):

  1. download used BOM :
    sbom-false-negatives.json
  2. run grype sbom:sbom-false-negatives.json
  3. receive no vulnerabilities
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]  
   ├── by severity: 0 critical, 0 high, 0 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 0 not-fixed, 0 ignored 
[0000]  WARN unable to determine linux distribution: unable to determine distro 
No vulnerabilities found

Please also include the grype command and any configuration used.
--> grype sbom:sbom-false-negatives.json
Anything else we need to know?:
I have run the software with hundreds of sboms in that particular format using cpes it always seemed to find vulnerabilities but in this case it didnot which i found peculiar given the quality of previous results

Environment:

  • Output of grype version:

Application: grype
Version: 0.86.1
BuildDate: 2024-12-13T19:32:52Z
GitCommit: 5c4fee7
GitDescription: v0.86.1
Platform: linux/amd64
GoVersion: go1.23.4
Compiler: gc
Syft Version: v1.18.1
Supported DB Schema: 5

  • OS (e.g: cat /etc/os-release or similar):

NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

Thank you for your support, bom was deliberately truncated from other irrelevant components and grype rerun on the truncated version
@jurassicLizard jurassicLizard added the bug Something isn't working label Jan 8, 2025
@jurassicLizard
Copy link
Author

this appears related to : #1560

@jurassicLizard jurassicLizard mentioned this issue Jan 9, 2025
Closed
@willmurphyscode
Copy link
Contributor

Hi @jurassicLizard, thanks for the issue!

Currently, Grype's database does not include type o or type h CPEs, only type a CPEs. There's a more detailed discussion at #872.

@jurassicLizard
Copy link
Author

@willmurphyscode thank you for your answer . I have read through the discussion and will post my follow up question there to keep the discussion linear.

@jurassicLizard jurassicLizard mentioned this issue Jan 15, 2025
Closed
@willmurphyscode
Copy link
Contributor

Adding needs-discussion so that we can discuss: Now that we have better compression and a more compressible schema, is it time to just include :h: and :o: CPEs in the database?

@joshbressers
Copy link
Contributor

@willmurphyscode Do we know of any possible downsides other than a larger DB?

I can think of two easy ones

  • We could see more false positive reports as I'm sure some of the CPEs are sort of broken
  • We could also see false negative reports as there are a lot of kernel CVEs missing CPEs

@jurassicLizard
Copy link
Author
jurassicLizard commented Mar 18, 2025 •
edited
Loading

@willmurphyscode how technically difficult it is to make :h: and : o : opt-in ? meaning have them in the database but need to be explicitly activated with a disclaimer information about possible extended false positives, it would help us in embedded use grype also in that setting and would not affect anyone else. maybe a separate repo that needs to be explicitly activated (opt-in) ? or just a command-line flag that allows em to be included with the default being o and h are masked ?

@wagoodman
Copy link
Contributor

We touched on it briefly in the livestream on thursday, essentially with the new DB schema adding CPEs with H and O part values would be cheap and easy. I have a change inbound that updates the DB build command to add these in by default anchore/grype-db#544 .

@wagoodman wagoodman mentioned this issue Mar 21, 2025
Merged
@jurassicLizard
Copy link
Author

well done thanks . In practical terms, this means we would need to build the db ourselves with the build command and cannot rely on the standard release. Or did I misunderstand ? Thank you

@wagoodman
Copy link
8000
Contributor

No need to build and DB locally or try an pull from an alternative source; since the PR landed today, tomorrow you should be able to see o CPE records:

$ grype db search 'cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:*'
[0000]  WARN ignoring version and update values for "cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:*"
VULNERABILITY   PACKAGE                                   ECOSYSTEM  NAMESPACE  VERSION CONSTRAINT
CVE-2006-2932   cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*             nvd:cpe
CVE-2007-3104   cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*             nvd:cpe    = 2.6.0
CVE-2008-3831   cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*             nvd:cpe    = 2.6.24
CVE-2009-4272   cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*             nvd:cpe    = 2.6.18
...

Which should see hits vulnerability matching-wise:

$ grype 'cpe:2.3:o:linux:linux_kernel:6.6.16:*:*:*:*:*:*:*'
 ✔ Scanned for vulnerabilities     [2 vulnerability matches]
   ├── by severity: 0 critical, 1 high, 1 medium, 0 low, 0 negligible
   └── by status:   0 fixed, 2 not-fixed, 0 ignored
NAME          INSTALLED  FIXED-IN  TYPE  VULNERABILITY  SEVERITY
linux_kernel  6.6.16                     CVE-2023-3079  High
linux_kernel  6.6.16                     CVE-2006-2932  Medium

It looks like there is an issue with the CPE matching logic for this case (we should have several more hits), I'll look into why that is the case today.

@wagoodman wagoodman self-assigned this Mar 24, 2025
@wagoodman wagoodman moved this to In Review in OSS Mar 24, 2025
@wagoodman wagoodman moved this from In Review to In Progress in OSS Mar 24, 2025
@westonsteimel
Copy link
Contributor
westonsteimel commented Mar 24, 2025 •
edited
Loading

Isn't it just that the db search command isn't properly taking into account the version part of the cpe whereas the match is? For instance, CVE-2007-3104 has a constraint of = 2.6.0, so not showing it as a match to 6.6.16 is correct (per the NVD data, not necessarily actually correct)

@wagoodman
Copy link
Contributor

Maybe, but I think there is a larger problem with how h & o CPEs are being included in the current DB:

/Users/wagoodman/code/grype-db/build/vulnerability.db> select * from cpes where part == "o" and vendor == "linux";
+------+------+--------+--------------+---------+----------+------------------+-----------------+-----------------+-------+
| id   | part | vendor | product      | edition | language | software_edition | target_hardware | target_software | other |
+------+------+--------+--------------+---------+----------+------------------+-----------------+-----------------+-------+
| 8380 | o    | linux  | linux_kernel |         |          |                  |                 |                 |       |
+------+------+--------+--------------+---------+----------+------------------+-----------------+-----------------+-------+
1 row in set
Time: 0.015s
/Users/wagoodman/code/grype-db/build/vulnerability.db> select * from affected_cpe_handles where cpe_id == 8380;
+--------+------------------+--------+---------+
| id     | vulnerability_id | cpe_id | blob_id |
+--------+------------------+--------+---------+
| 20497  | 18693            | 8380   | 36820   |
| 29173  | 25996            | 8380   | 51825   |
| 38158  | 33260            | 8380   | 67023   |
| 48352  | 40855            | 8380   | 83040   |
| 50207  | 42454            | 8380   | 86299   |
| 52889  | 44617            | 8380   | 90857   |
| 129297 | 107249           | 8380   | 214666  |
| 156981 | 131117           | 8380   | 260332  |
| 189172 | 147454           | 8380   | 290680  |
| 
8000
284393 | 224791           | 8380   | 435597  |
+--------+------------------+--------+---------+
10 rows in set
Time: 0.019s

Though we're pulling in ~10,000 extra CPEs (mostly h CPEs) it seems that we are not parsing the CPE node configuration correctly to consider these CPE parts (I think there is a bias to create packages for a types only for known-node configuration structures).

@wagoodman
Copy link
Contributor
wagoodman commented Mar 24, 2025 •
edited
Loading

Well, there's a problem with how I'm looking at this: just because we're including hardware and OS CPEs doesn't mean that we can match on them. In fact we still have a CPE filter in grype DB that still filters based off of primarily application CPEs. In order to truely include all hardware and OS CPEs and leverage it for matching we'd need to match the OS information directly with CPEs absent of a reference package -- a capability we don't have today.

I think this issue is really not a bug but actually a feature request to do just that: match distro objects directly with what's in the DB. [EDIT] I'm getting ahead of myself, we're still talking about the linux_kernel package that we're trying to match against. This might just be an exception in the sense that NVD considers this to be an o type but this is just a component of the OS and in reality this is observable as a package, thus we want to be able to match against these CPEs as if they were a parts (like we do packages).

@wagoodman wagoodman moved this from In Progress to Ready in OSS Mar 24, 2025
@wagoodman wagoodman moved this from Ready to In Progress in OSS Mar 24, 2025
@jurassicLizard
Copy link
Author

Thank you !

@wagoodman
Copy link
Contributor

Once anchore/grype-db#546 lands, I'll cut a release of grype-db in which case the next DB build will have the additional H & O CPEs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@wagoodman wagoodman

Labels
bug Something isn't working
Projects
OSS
Status: In Progress
Milestone
No milestone
Development

No branches or pull requests
5 participants
@wagoodman @westonsteimel @joshbressers @willmurphyscode @jurassicLizard
0