False positive - Ruby libraries identified as other software

[luislavena]

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 date applies to Drupal module, not Ruby's date gem
• 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-release from 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.

[alfredodeza]

@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!

[alfredodeza]

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 =

[luislavena]

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.

[sparrowt]

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?

[sparrowt]

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

[vbr-cts]

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:*:*:*:*:*:*:*:*"
      ]
     }
    }
   ],

[willmurphyscode]

I'm still able to reproduce the issues mentioned in #244 (comment).

 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.

[willmurphyscode]

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.

[luislavena]

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!
❤️ ❤️ ❤️