grype
grype copied to clipboard
anchore
False positive - Ruby libraries identified as other software
What happened:
grype reports certain Ruby gems as CVE for Drupal, Node and other non-programming related (ranges from High to Low).
What you expected to happen:
Grype states scans for vulnerabilities in Ruby (Bundler) which can be interpreted as gems (the package system used by Ruby).
How to reproduce it (as minimally and precisely as possible):
❯ docker pull ruby:3.0.0-alpine
...
❯ grype ruby:3.0.0-alpine
✔ Vulnerability DB [no update available]
✔ Loaded image
✔ Parsed image
✔ Cataloged image [122 packages]
✔ Scanned image [14 vulnerabilities]
NAME INSTALLED FIXED-IN VULNERABILITY SEVERITY
date 3.1.0 CVE-2014-5169 Low
delegate 0.2.0 CVE-1999-1338 Medium
delegate 0.2.0 CVE-2005-0036 Medium
delegate 0.2.0 CVE-2005-0861 High
json 2.5.1 CVE-2020-7712 High
logger 1.4.3 CVE-2017-14727 High
matrix 0.3.1 CVE-2017-14197 Medium
matrix 0.3.1 CVE-2017-14198 High
observer 0.1.1 CVE-2008-4318 High
openssl 2.2.0 CVE-2018-12433 Medium
openssl 2.2.0 CVE-2018-12438 Medium
openssl 2.2.0 CVE-2018-12437 Medium
readline 0.0.2 CVE-2014-2524 Low
zlib 1.1.0 CVE-2002-0059 High
-
CVE-2014-5169 for
dateapplies to Drupal module, not Ruby'sdategem - CVE-1999-1338 applies to DeleGate, a multi-protocol proxy
- CVE-2017-14198 applies to Squiz Matrix and not Ruby's matrix gem.
It appears most of these reports are false positives or other libraries with same names but different languages.
Environment:
- Output of
grype version:
❯ grype version
Application: grype
Version: 0.7.0
BuildDate: 2021-01-28T14:03:23Z
GitCommit: 8344b8f0d3f61729cf0845c08b31f26103e21231
GitTreeState: clean
Platform: linux/amd64
GoVersion: go1.14.14
Compiler: gc
Supported DB Schema: 1
- Vulnerability DB information:
❯ grype db status
Location: /home/luis/.cache/grype/db
Built: 2021-03-07 08:26:25 +0000 UTC
Current DB Version: 1
Require DB Version: 1
Status: Valid
- OS (e.g:
cat /etc/os-releasefrom container):
$ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.13.2
PRETTY_NAME="Alpine Linux v3.13"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"
Unsure how to proceed or how to help correct these false positives.
Thank you in advance for time and most importantly, for making grype available to the world! ❤️ ❤️ ❤️
Cheers.
@luislavena thanks for reporting this one. We have a few False Positive issues that are coming up that we are trying to resolve. Let's definitely keep this one open to track it - we appreciate the detail in the report!
Expanding on here, I believe that this is again related to CPE matching being too broad:
sqlite> select * from vulnerability where id == "CVE-2014-5169";
pk = 395392
id = CVE-2014-5169
record_source = nvdv2:nvdv2:cves
package_name = date
namespace = nvd
version_constraint = <= 7.x-2.7
version_format = unknown
cpes = ["cpe:2.3:a:date_project:date:*:*:*:*:*:drupal:*:*"]
proxy_vulnerabilities = []
fixed_in_version =
Thank you @alfredodeza for your response and the context. Please let me know if there is anything else I could help with, including provide test repositories or similar 😊 (haven't learn Go in order to say can do some coding, hehe).
Once again, thank you for making grype available! ❤️ ❤️ ❤️
Cheers.
The same seems to have started happening for zlib presumably due to a vuln DB update (given I remained on v0.43.0 - though 0.47.0 has the same problem)
docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock anchore/grype:v0.47.0 fluent/fluentd:v1.14.4-1.0
output includes:
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
...
zlib 1.1.0 gem CVE-2002-0059 High
zlib 1.1.0 gem CVE-2022-37434 Critical
zlib 1.1.0 1.2.12 gem CVE-2018-25032 High
There are also some zlib rows of type apk (omitted here for clarity) which are correctly flagged (the zlib baked into alpine needs updating from 1.2.11 to fix those CVEs).
However the 3 zlib lines of type gem are wrong AFAICS - https://rubygems.org/gems/zlib/ doesn't have a 1.2.12 (so you can't upgrade to it to fix CVE-2018-25032) but also I don't believe that gem actually contains the zlib code, it is simply a Ruby interface to it.
So grype shouldn't be reporting these CVEs for bugs in the actual zlib library, against the version of the Ruby zlib interface package.
Is this the correct ticket for that, or should I open a separate one?
Interestingly the very day after my comment, the vuln DB update (from 2022-08-25 08:17:54 +0000 UTC => 2022-08-26 08:18:08 +0000 UTC) removed the 'FIXED-IN' from the false-positive gem zlib for CVE-2018-25032, so the output is now:
NAME INSTALLED FIXED-IN TYPE VULNERABILITY SEVERITY
zlib 1.1.0 gem CVE-2002-0059 High
zlib 1.1.0 gem CVE-2022-37434 Critical
zlib 1.1.0 gem CVE-2018-25032 High
however it is still wrong - those CVEs are just not applicable to the Ruby gem interface package called zlib
Having the same issue with the redis gem.
Syft (0.56.0) defines the following cpes in the sbom:
"cpes": [
"cpe:2.3:a:ruby-lang:redis:4.8.0:*:*:*:*:*:*:*",
"cpe:2.3:a:ruby_lang:redis:4.8.0:*:*:*:*:*:*:*",
"cpe:2.3:a:redis:redis:4.8.0:*:*:*:*:*:*:*",
"cpe:2.3:a:ruby:redis:4.8.0:*:*:*:*:*:*:*",
"cpe:2.3:a:*:redis:4.8.0:*:*:*:*:*:*:*"
],
Grype then flags it for CVE-2018-12453 (and a bunch of others) that actually impacts the redis server, and not the client lib. The versions are totally unrelated. This is because the redislab vendor in the CPE of the CVE matches the * in the sbom.
"matchDetails": [
{
"type": "cpe-match",
"matcher": "ruby-gem-matcher",
"searchedBy": {
"namespace": "nvd:cpe",
"cpes": [
"cpe:2.3:a:*:redis:4.8.0:*:*:*:*:*:*:*"
]
},
"found": {
"versionConstraint": "< 5.0 (unknown)",
"cpes": [
"cpe:2.3:a:redislabs:redis:*:*:*:*:*:*:*:*"
]
}
}
],
I'm still able to reproduce the issues mentioned in https://github.com/anchore/grype/issues/244#issuecomment-1227107569.
grype --platform linux/amd64 docker:fluent/fluentd:v1.14.4-1.0 | grep -e CVE-2018-25032 -e CVE-2022-37434 -e CVE-2002-0059
prints the following vulnerabilities:
zlib 1.1.0 gem CVE-2002-0059 High
zlib 1.1.0 gem CVE-2018-25032 High
zlib 1.1.0 gem CVE-2022-37434 Critical
zlib 1.2.11-r3 1.2.12-r0 apk CVE-2018-25032 High
zlib 1.2.11-r3 1.2.12-r2 apk CVE-2022-37434 Critical
I'm not able to reproduce the false positives from the original post on this issue, but it could be that ruby:3.0.0-alpine has moved since this issue was opened.
In https://github.com/anchore/grype/releases/tag/v0.60.0, grype stopped matching on javascript CPEs by default for exactly this sort of issue, but I believe the Ruby ecosystem still matches on CPEs by default. It might be worth looking for a different way to match Ruby CVEs than relying on CPEs.
Hi @luislavena, thanks for the report! The reason this was happening was that Grype used to use CPEs to match ruby gems to vulnerabilities, and CPEs don't have any mechanism to namespace them by ecosystem. Since the issue was opened, Grype has switched to using the information in PURLs for language ecosystem matching, so I believe this class of issue is no longer present on recent versions of Grype on default configuration, so I'm going to close this, since I think the original request is solved.
Please let us know if we missed something.
Hello @willmurphyscode, indeed this issue no longer appears (well, except for all the newer CVE's found in Alpine, but that has nothing to do with Grype! 😅 )
Thank you for following up on this! ❤️ ❤️ ❤️