false positives in logstash image

[kingjs10]

What happened:
Image from opensearch/elastic shows false positives
https://hub.docker.com/r/opensearchproject/logstash-oss-with-opensearch-output-plugin

CVE-2014-9390
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/git-1.9.1.gemspec"

CVE-2015-7545
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/git-1.9.1.gemspec"

CVE-2016-2324
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/git-1.9.1.gemspec"

CVE-2018-19486
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/git-1.9.1.gemspec"

CVE-2019-5477
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/nokogiri-1.12.5-java/lib/nokogiri/nokogiri.jar"
Vulnerable version is v1.10.3, this is version 1.12.5
https://github.com/sparklemotion/nokogiri/releases/tag/v1.12.5
https://nvd.nist.gov/vuln/detail/CVE-2019-5477

CVE-2022-0543
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/redis-4.5.1.gemspec"

CVE-2022-25648
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/git-1.9.1.gemspec"

GHSA-69p6-wvmq-27gg
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/git-1.9.1.gemspec"

GHSA-h99w-9q5r-gjq9
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/specifications/puma-5.5.2-java.gemspec"

What you expected to happen:
gemspec files shouldn't be flagged

How to reproduce it (as minimally and precisely as possible):
grype opensearchproject/logstash-oss-with-opensearch-output-plugin

Anything else we need to know?:
CVE-2019-5477
"path": "/usr/share/logstash/vendor/bundle/jruby/2.5.0/gems/nokogiri-1.12.5-java/lib/nokogiri/nokogiri.jar"
is picked up even though it's not the correct version

Environment:

• Output of grype version:
  ➜ ~ grype version 16:00:20
  Application: grype
  Version: 0.40.1
  Syft Version: v0.49.0
  BuildDate: 2022-06-24T18:56:01Z
  GitCommit: 82c0146
  GitDescription: v0.40.1
  Platform: darwin/arm64
  GoVersion: go1.18.3
  Compiler: gc
  Supported DB Schema: 3
• OS (e.g: cat /etc/os-release or similar):
  Darwin computername 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar 18 00:46:32 PDT 2022; root:xnu-8020.101.4~15/RELEASE_ARM64_T6000 arm64

[spiffcs]

Thanks for the issue @kingjs10. I'm working on a few other issues at the moment, but I made sure to give this the correct false positive label so that we can keep track of why some of these vulnerabilities are being incorrectly flagged.

[willmurphyscode]

Thanks @kingjs10 for reporting this issue. I'm going to see what parts of it can still be reproduced, since several false positives are reported.

grype --platform linux/amd64 \
opensearchproject/logstash-oss-with-opensearch-output-plugin:latest@sha256:dc060b364d600858fca6b86f9217bdd0c28ecbc5c1a0636538dd6d946422a421 | \
grep -e CVE-2014-9390 -e CVE-2015-7545 -e CVE-2016-2324 \
-e CVE-2018-19486 -e CVE-2019-5477 -e CVE-2022-0543 -e CVE-2022-25648 \
-e GHSA-69p6-wvmq-27gg -e GHSA-h99w-9q5r-gjq9 -e CVE-2019-5477

prints the following vulnerabilities:

nokogiri                                                                      java-archive  CVE-2019-5477        Critical    
redis                 4.8.0                                                   gem           CVE-2022-0543        Critical  

Let's gather some more details on each of them:

CVE-2019-5477 from https://nvd.nist.gov/vuln/detail/CVE-2019-5477
matched artifact is:
nokogiri - pkg:maven/nokogiri/nokogiri
match type is cpe-match
CPEs

• cpe:2.3:a:nokogiri:nokogiri:*:*:*:*:*:*:*:*

URLs:

• https://nvd.nist.gov/vuln/detail/CVE-2019-5477
• CVE-2019-5477 - Nokogiri Command Injection Vulnerability sparklemotion/nokogiri#1915
• https://github.com/tenderlove/rexical/blob/master/CHANGELOG.rdoc
• https://hackerone.com/reports/650835
• https://lists.debian.org/debian-lts-announce/2019/09/msg00027.html
• https://lists.debian.org/debian-lts-announce/2022/10/msg00018.html
• https://lists.debian.org/debian-lts-announce/2022/10/msg00019.html
• https://security.gentoo.org/glsa/202006-05
• https://usn.ubuntu.com/4175-1/

CVE-2022-0543 from https://nvd.nist.gov/vuln/detail/CVE-2022-0543
matched artifact is:
redis - pkg:gem/[email protected]
match type is cpe-match
CPEs

• cpe:2.3:a:salvatore-sanfilippo:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:salvatore_sanfilippo:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:ezra-zygmuntowicz:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:ezra_zygmuntowicz:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:pieter-noordhuis:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:pieter_noordhuis:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:damian-janowski:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:damian_janowski:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:brian-mckinney:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:brian_mckinney:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:michel-martens:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:michel_martens:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:taylor-weibley:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:taylor_weibley:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:matthew-clark:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:matthew_clark:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:luca-guidi:redis:4.8.0:*:*:*:*:*:*:*
• cpe:2.3:a:luca_guidi:redis:4.8.0:*:*:*:*:*:*:*
• 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:*:*:*:*:*:*:*

URLs:

• https://nvd.nist.gov/vuln/detail/CVE-2022-0543
• http://packetstormsecurity.com/files/166885/Redis-Lua-Sandbox-Escape.html
• https://bugs.debian.org/1005787
• https://lists.debian.org/debian-security-announce/2022/msg00048.html
• https://security.netapp.com/advisory/ntap-20220331-0004/
• https://www.debian.org/security/2022/dsa-5081
• https://www.ubercomp.com/posts/2022-01-20_redis_on_debian_rce

This comment is long, but I'll try to do a little digging on why we're not regarding the version number for the nokogiri jar. It looks like some things have been upgraded in the image since the original comment as well. So the remaining questions I have are:

1. What version of nokogiri-java is now in the image, and if it is patched, why does grype still show a CVE?
2. Does https://nvd.nist.gov/vuln/detail/CVE-2022-0543#match-7772249, which is a debian packaging issue, affect opensearchproject/logstash-oss-with-opensearch-output-plugin:latest?

[willmurphyscode]

Taking the second question first, let's try to see what flavor of Linux this logstash image is based on:

docker run --platform linux/amd64 -ti \
opensearchproject/logstash-oss-with-opensearch-output-plugin:latest@sha256:dc060b364d600858fca6b86f9217bdd0c28ecbc5c1a0636538dd6d946422a421 \
cat /etc/os-release  

prints

NAME="Ubuntu"
VERSION="20.04.5 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.5 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

So the image is built from Ubuntu, so it's not unreasonable to think that a Debian packaging vulnerability affects it. Additionally, https://packetstormsecurity.com/files/166885/Redis-Lua-Sandbox-Escape.html, which is one of the related URLs from the CVE, says:

The vulnerability was introduced by Debian and Ubuntu Redis packages that insufficiently sanitized the Lua environment

So we'll need to do some digging to see which version of Ubuntu may have fixed this. https://nvd.nist.gov/vuln/detail/CVE-2022-0543#match-7772249 lists debian 9.0, 10.0, and 11.0, but I'm not sure which versions of Ubuntu may have the fix.

Edit: It looks like, assuming https://askubuntu.com/a/445496 is correct, that Ubuntu Focal Fossa is based on Debian 10.

[willmurphyscode]

The nokogiri one is interesting; I'm not sure what to make of it.

Running:

grype -o json opensearchproject/logstash-oss-with-opensearch-output-plugin > /tmp/grype816.json
cat grype816.json| grype explain --id CVE-2019-5477

Prints:
[0000] WARN grype explain is a prototype feature and is subject to change
CVE-2019-5477 from nvd:cpe (Critical)
A command injection vulnerability in Nokogiri v1.10.3 and earlier allows commands to be executed in a subprocess via Ruby's Kernel.open method. Processes are vulnerable only if the undocumented method Nokogiri::CSS::Tokenizer#load_file is being called with unsafe user input as the filename. This vulnerability appears in code generated by the Rexical gem versions v1.0.6 and earlier. Rexical is used by Nokogiri to generate lexical scanner code for parsing CSS queries. The underlying vulnerability was addressed in Rexical v1.0.7 and Nokogiri upgraded to this version of Rexical in Nokogiri v1.10.4.
Matched packages:
- Package: nokogiri, version:
PURL: pkg:maven/nokogiri/nokogiri
Match explanation(s):
- nvd:cpe:CVE-2019-5477 CPE match on cpe:2.3:a:nokogiri:nokogiri:*:*:*:*:*:*:*:*.
Locations:
- /usr/share/logstash/vendor/bundle/jruby/2.6.0/gems/nokogiri-1.13.10-java/lib/nokogiri/nokogiri.jar
URLs:
- https://nvd.nist.gov/vuln/detail/CVE-2019-5477

This seems clearly to be a false positive, for a couple of reasons: 1. The version of nokogiri present is 1.13.10, but the issue was fixed in nokogiri 1.10.4, and the artifact reported as vulnerable is the jruby implementation of nokogiri.jar, which (probably?) doesn't have the same vulnerabilities as the normal ruby interpreter's Kernel.open.

The purl we generated, pkg:maven/nokogiri/nokogiri, is interesting too - it's treated as a maven packages, probably because it's a *.jar, but has no version information.

I'm really not sure how we ought to handle JRuby gems, since they aren't clearly the responsibility of the Java matcher or the Ruby matcher.

The other false positives reported in @kingjs10 's original post don't seem to appear any more; I'm not sure whether they were fixed in grype, or the image tag moved.