grype False positive CVE-2015-5237 for protobuf-go

What happened: Our go.mod dependency of google.golang.org/[email protected] (a.k.a https://github.com/protocolbuffers/protobuf-go) is detected by syft/grype as cpe:2.3:a:google:protobuf:v1.27.1:*:*:*:*:*:*:* and grype matches CVE-2015-5237 based on cpe:2.3:a:google:protobuf:*:*:*:*:*:*:*:* <= 3.1.0 but 1.27.1 is the latest version.

The CVE links to https://github.com/protocolbuffers/protobuf/issues/760 which is a different project (protobuf language spec vs the golang runtime).

What you expected to happen: Distinguish between google.golang.org/protobuf and github.com/protocolbuffers/protobuf

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

mkdir -p /tmp/gomod/
echo '
module foo
go 1.17
require google.golang.org/protobuf v1.27.1' > /tmp/gomod/go.mod
grype dir:/tmp/gomod

Anything else we need to know?: https://github.com/golang/vuln/blob/master/triaged-cve-list marks CVE-2015-5237 as a false postive - but I'm not sure what package/version that refers to.

Environment:

Output of grype version:

Application:          grype
Version:              0.27.3
Syft Version:         v0.33.0
BuildDate:            2021-12-16T15:11:16Z
GitCommit:            4f964c4ee26ad01a80b8bcffb6bf23c0afb71d09
GitTreeState:         clean
Platform:             darwin/amd64
GoVersion:            go1.16.12
Compiler:             gc
Supported DB Schema:  3

OS (e.g: cat /etc/os-release or similar): MacOS Big Sur 11.6.2

Dec 20 '21 16:12 cjnosal

Match from grype -o json

"matches": [
  {
   "vulnerability": {
    "id": "CVE-2015-5237",
    "dataSource": "https://nvd.nist.gov/vuln/detail/CVE-2015-5237",
    "namespace": "nvd",
    "severity": "High",
    "urls": [
     "https://github.com/google/protobuf/issues/760",
     "https://bugzilla.redhat.com/show_bug.cgi?id=1256426",
     "http://www.openwall.com/lists/oss-security/2015/08/27/2",
     "https://lists.apache.org/thread.html/b0656d359c7d40ec9f39c8cc61bca66802ef9a2a12ee199f5b0c1442@%3Cdev.drill.apache.org%3E",
     "https://lists.apache.org/thread.html/519eb0fd45642dcecd9ff74cb3e71c20a4753f7d82e2f07864b5108f@%3Cdev.drill.apache.org%3E",
     "https://lists.apache.org/thread.html/ra28fed69eef3a71e5fe5daea001d0456b05b102044237330ec5c7c82@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/f9bc3e55f4e28d1dcd1a69aae6d53e609a758e34d2869b4d798e13cc@%3Cissues.drill.apache.org%3E",
     "https://lists.apache.org/thread.html/r17dc6f394429f6bffb5e4c66555d93c2e9923cbbdc5a93db9a56c1c7@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r42e47994734cd1980ef3e204a40555336e10cc80096927aca2f37d90@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/re6d04a214424a97ea59c62190d79316edf311a0a6346524dfef3b940@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r1263fa5b51e4ec3cb8f09ff40e4747428c71198e9bee93349ec96a3c@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r42ef6acfb0d86a2df0c2390702ecbe97d2104a331560f2790d17ca69@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/rb71dac1d9dd4e8a8ae3dbc033aeae514eda9be1263c1df3b42a530a2@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r320dc858da88846ba00bb077bcca2cdf75b7dde0f6eb3a3d60dba6a1@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r85c9a764b573c786224688cc906c27e28343e18f5b33387f94cae90f@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r02e39d7beb32eebcdbb4b516e95f67d71c90d5d462b26f4078d21eeb@%3Cuser.flink.apache.org%3E",
     "https://lists.apache.org/thread.html/r02e39d7beb32eebcdbb4b516e95f67d71c90d5d462b26f4078d21eeb@%3Cdev.flink.apache.org%3E",
     "https://lists.apache.org/thread.html/r5e52caf41dc49df55b4ee80758356fe1ff2a88179ff24c685de7c28d@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/rf7539287c90be979bac94af9aaba34118fbf968864944b4871af48dd@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r1d274d647b3c2060df9be21eade4ce56d3a59998cf19ac72662dd994@%3Ccommits.pulsar.apache.org%3E",
     "https://lists.apache.org/thread.html/r4886108206d4c535db9b20c813fe4723d4fe6a91b9278382af8b9d08@%3Cissues.spark.apache.org%3E",
     "https://lists.apache.org/thread.html/rb40dc9d63a5331bce8e80865b7fa3af9dd31e16555affd697b6f3526@%3Cissues.spark.apache.org%3E",
     "https://lists.apache.org/thread.html/r5741f4dbdd129dbb9885f5fb170dc1b24a06b9313bedef5e67fded94@%3Cissues.spark.apache.org%3E",
     "https://lists.apache.org/thread.html/r14fa8d38d5757254f1a2e112270c996711d514de2e3b01c93d397ab4@%3Cissues.spark.apache.org%3E",
     "https://lists.apache.org/thread.html/r2ea33ce5591a9cb9ed52750b6ab42ab658f529a7028c3166ba93c7d5@%3Ccommon-issues.hadoop.apache.org%3E",
     "https://lists.apache.org/thread.html/r00d9ab1fc0f1daf14cd4386564dd84f7889404438d81462c86dfa836@%3Ccommon-dev.hadoop.apache.org%3E",
     "https://lists.apache.org/thread.html/r764fc66435ee4d185d359c28c0887d3e5866d7292a8d5598d9e7cbc4@%3Ccommon-issues.hadoop.apache.org%3E",
     "https://lists.apache.org/thread.html/r0ca83171c4898dc92b86fa6f484a7be1dc96206765f4d01dce0f1b28@%3Ccommon-issues.hadoop.apache.org%3E",
     "https://lists.apache.org/thread.html/r00097d0b5b6164ea428554007121d5dc1f88ba2af7b9e977a10572cd@%3Cdev.hbase.apache.org%3E",
     "https://lists.apache.org/thread.html/rd64381fb8f92d640c1975dc50dcdf1b8512e02a2a7b20292d3565cae@%3Cissues.hbase.apache.org%3E",
     "https://lists.apache.org/thread.html/r4ef574a5621b0e670a3ce641e9922543e34f22bf4c9ee9584aa67fcf@%3Cissues.hbase.apache.org%3E",
     "https://lists.apache.org/thread.html/r7fed8dd9bee494094e7011cf3c2ab75bd8754ea314c6734688c42932@%3Ccommon-issues.hadoop.apache.org%3E"
    ],
    "description": "protobuf allows remote authenticated attackers to cause a heap-based buffer overflow.",
    "cvss": [
     {
      "version": "2.0",
      "vector": "AV:N/AC:L/Au:S/C:P/I:P/A:P",
      "metrics": {
       "baseScore": 6.5,
       "exploitabilityScore": 8,
       "impactScore": 6.4
      },
      "vendorMetadata": {}
     },
     {
      "version": "3.1",
      "vector": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "metrics": {
       "baseScore": 8.8,
       "exploitabilityScore": 2.8,
       "impactScore": 5.9
      },
      "vendorMetadata": {}
     }
    ],
    "fix": {
     "versions": [],
     "state": "unknown"
    },
    "advisories": []
   },
   "relatedVulnerabilities": [],
   "matchDetails": [
    {
     "matcher": "stock-matcher",
     "searchedBy": {
      "namespace": "nvd",
      "cpes": [
       "cpe:2.3:a:google:protobuf:v1.27.1:*:*:*:*:*:*:*"
      ]
     },
     "found": {
      "versionConstraint": "<= 3.1.0 (unknown)",
      "cpes": [
       "cpe:2.3:a:google:protobuf:*:*:*:*:*:*:*:*"
      ]
     }
    }
   ],
   "artifact": {
    "name": "google.golang.org/protobuf",
    "version": "v1.27.1",
    "type": "go-module",
    "locations": [
     {
      "path": "go.mod"
     }
    ],
    "language": "go",
    "licenses": [],
    "cpes": [
     "cpe:2.3:a:google:protobuf:v1.27.1:*:*:*:*:*:*:*"
    ],
    "purl": "pkg:golang/google.golang.org/[email protected]",
    "metadata": null
   }
  }
 ]

Dec 20 '21 16:12 cjnosal

Thanks for reporting the issue @xtreme-conor-nosal - I'll take a look and see if we can resolve this so that this is no longer being reported as a false positive.

Jan 07 '22 16:01 spiffcs

Do you please have some news? This one is blocking my CI...

Jan 26 '22 22:01 fjammes

Sure @fjammes! We're still trying to work out where we want to go with CPE generation so it's not such a moving target where we always see FPS.

In the meantime, if you're having a current issue where a vuln is blocking your CI, would you be able to use the Ignore functionality listed here.

Jan 27 '22 14:01 spiffcs

This also seems to be a false-positive with https://animal.uk.oracle.com/CVE-2021-22570. Same symptoms. Do we need a separate bug for that?

Feb 08 '22 13:02 michael-cico

We can keep this under this bug thanks for the follow-up!

Feb 08 '22 17:02 spiffcs

👍 thanks

Feb 08 '22 20:02 michael-cico

I can confirm this is still the case - we are experiencing the same for flux cli:

$ curl -sSfL https://github.com/fluxcd/flux2/releases/download/v0.28.4/flux_0.28.4_sbom.spdx.json | grype

NAME                        INSTALLED  FIXED-IN  VULNERABILITY   SEVERITY 
google.golang.org/protobuf  v1.27.1              CVE-2015-5237   High      
google.golang.org/protobuf  v1.27.1              CVE-2021-22570  High

Mar 29 '22 17:03 pjbgf

Same false positive with google.golang.org/protobuf v1.28.0 ... any hope for a fix ?

May 22 '22 20:05 avermeer

@avermeer we're working on a solution to factor this out, however, you can also be sure that grype is not executing the vulnerable code on any of its paths and that the related libraries are pulled in as a transitive dependency. At no time do we expose any kind of protobuff interface for authentication or generate any proto file during grype operations:

Vulnerability details below for CVE-2021-22570

Nullptr dereference when a null char is present in a proto symbol. 
The symbol is parsed incorrectly, leading to an unchecked call into the proto 
file's name during generation of the resulting error message. 
Since the symbol is incorrectly parsed, the file is nullptr. 
We recommend upgrading to version 3.15.0 or greater.

CVE-2015-5237

protobuf allows remote authenticated attackers to cause a heap-based buffer overflow.

Jun 01 '22 13:06 spiffcs

is there any update on this. This is still being flagged widely by grype.

Aug 16 '22 23:08 jaskaransinghdr6j

We also spot the same issue CVE-2015-5237 detected for protobuf-go as google.golang.org/protobuf for different golang apps. Apparently this is NVD that has invalid or outdated CPEs[] https://nvd.nist.gov/vuln/detail/CVE-2015-5237/cpes?expandCpeRanges=true at the same time the GHSA^ equivalent has the correct values (see Packages impacted its linked to proper github.com/protocolbuffers/protobuf ) https://github.com/advisories/GHSA-jwvw-v7c5-m82h Just a note: if I disable CPE matching (using-cpes) then this vuln isn't detected. I wonder what can be the fix for this issue: if there is GHSA^ in RelatedVulnerabilities, we can try to use CPEs from it instead of relying on what comes with NVD. Any other ideas we can try?

Sep 12 '22 07:09 olevchyk

So what we are planning to do here is to eventually disable CPE-based matching by default. @wagoodman is currently working on getting a quality check implemented within Grype so that on each commit we can understand the difference in detection of false-positives and ensure there aren't any false-negatives introduced as part of a change. We are also working on bringing in an additional source of vulnerability data from GitLab's Community Advisory Database to provide additional coverage for some ecosystems (java Maven in particular). We believe that with both of those in place we can safely turn off the CPE-based matching by default without introducing many false-negatives that would have been found by the CPE-based matches and eliminate the flood of false-positives that it generates

Sep 12 '22 08:09 westonsteimel

How can we disable CPE matching right now?

Sep 28 '22 22:09 jaskaransinghdr6j

You can disable per matcher in the config file https://github.com/anchore/grype#configuration by setting using-cpes: false

match:
  # sets the matchers below to use cpes when trying to find 
  # vulnerability matches. The stock matcher is the default
  # when no primary matcher can be identified 
  java:
    using-cpes: true
  python:
    using-cpes: true
  javascript:
    using-cpes: true
  ruby:
    using-cpes: true
  dotnet:
    using-cpes: true
  golang:
    using-cpes: true
  stock:
    using-cpes: true

Sep 28 '22 22:09 westonsteimel

you can also control it with env variables if that's easier for you, example for golang

export GRYPE_MATCH_GOLANG_USING_CPES=false

Sep 29 '22 12:09 olevchyk

Thanks, this works! Worried if this will result in False negatives though.

Sep 29 '22 20:09 jaskaransinghdr6j

We encountered the same issue on the following environment What happened: In a Vulnerability Scanner Benchmark Research we are conducting, we executed Grype on 20 different containers and found out that Grype has multiple False Positives. What you expected to happen: We expected Grype not to report on these CVEs. How to reproduce it (as minimally and precisely as possible): Install the Docker Images (from the links below) and execute Grype using the following command: grype <container_name> —-output json > <output_file_path>

Output of grype version: Application: grype Version: 0.41.0 Syft Version: v0.50.0 BuildDate: 2022-07-06T15:20:18Z GitCommit: 0e0a9d9e7a28592db489499db0294608e5fe69b8 GitDescription: v0.41.0 Platform: linux/amd64 GoVersion: go1.18.3 Compiler: gc Supported DB Schema: 4

Consul

Container Details: https://hub.docker.com/layers/library/consul/1.12.2/images/sha256-a1a933572cb6f6388501c535af455f77e687c62ff97ed72cd16301b8b535eae0?context=explore
OS (e.g: cat /etc/os-release): NAME="Alpine Linux" ID=alpine VERSION_ID=3.15.4 PRETTY_NAME="Alpine Linux v3.15" HOME_URL="https://alpinelinux.org/" BUG_REPORT_URL="https://bugs.alpinelinux.org/"
CVEs CVE-2015-5237 and CVE-2021-22570 Grype wrondly identifies protobuf CVE-2015-5237 and CVE-2021-22570 as vulnerable. The protobuf CVE-2015-5237 vulnerability affected versions are Up to (including) 3.1.0. The protobuf CVE-2021-22570 vulnerability affected versions are Up to (including) 3.15.0. Grype identified the consul as affected because it says that it uses the protobuf as a go module and the version is 1.25.0. Affected protobuf versions are Up to (including) 3.1.0. Using strings on the consul elf file, we found that the file has a dependency of protobuf version 1.25.0 - dep google.golang.org/protobuf v1.25.0 . The version is within the affected range.

Solr

Container Details: https://hub.docker.com/layers/library/solr/9.0.0/images/sha256-a75d693dcc9b978f8f35cdad3f775ad09dd3020e1920871a1fb167655a19e888?context=explore
OS (e.g: cat /etc/os-release): PRETTY_NAME="Ubuntu 22.04 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian 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" UBUNTU_CODENAME=jammy
CVEs CVE-2021-22570 Grype wrongly identified protobuf CVE-2021-22570 as vulnerable. Affected versions are: Up to (excluding) 3.15.0. Grype finds the protobuf-java package version as: 3.7.1. According to ubuntu: Jammy - Needed. The affected protobuf package is a google package and not a java package.

Oct 02 '22 12:10 OfriOuzan

If you all are open to a hard-coded fix for this in the meantime, I'm happy to submit a PR!

Jan 19 '23 15:01 luhring

much appreciated @luhring -- I think a hard coded fix for this one is worth it given the number of folks impacted by this. Thanks in advance 🙏 !

Jan 19 '23 15:01 wagoodman

grype grype copied to clipboard

False positive CVE-2015-5237 for protobuf-go

grype
grype copied to clipboard