search

anchore / syft

CLI tool and library for generating a Software Bill of Materials from container images and filesystems
Apache License 2.0
6.2k stars 571 forks source link

Grype is not reporting CVE-2017-15708 #333

Closed enggabhishekshinde closed 3 years ago

enggabhishekshinde commented 3 years ago

What happened: I scanned container known security vulnerability of library commons-collections version 3.1. It should report critical CVE-2017-15708 by grype. I have used twistlock tool for security vulnerability. It's reported by twistlock. But it's not reported by grype

What you expected to happen: Grype should be reporting CVE-2017-15708 CVE.

How to reproduce it (as minimally and precisely as possible): You can download hibernate-core version 3.5.0-Final jar file and include it in any container. Scan that container.

Anything else we need to know?: https://nvd.nist.gov/vuln/detail/CVE-2017-15708

Environment:

enggabhishekshinde commented 3 years ago

CVE-2017-15708 id is present in vulnerability.db. But while scanning the image, it's not reporting CVE-2017-15708 vulnerability. I think Grype is not scanning the jar embedded into jar. I think we need to fix this issue. We should scan embedded jars which are present into jar file by using mvn dependency:tree.

Here is example - commons-collections jar file present into hibernate-core 3.5.0-Final jar file. I think Grype is not scanning jar files present into hibernate-core 3.5.0-Final jar file. We can do it by using mvn dependency:tree of hibernate-core 3.5.0-Final jar.

luhring commented 3 years ago

Hi @enggabhishekshinde, thanks for the submission. I'm trying to reproduce this...

When I download the hibernate-core 3.5.0-Final JAR file (from https://repo1.maven.org/maven2/org/hibernate/hibernate-core/3.5.0-Final/hibernate-core-3.5.0-Final.jar), I don't see any JAR files contained inside the downloaded JAR file.

I'll admit, I'm not very strong with the Java ecosystem.

To reproduce, it'd be great to have a container image for which Grype should surface CVE-2017-15708. Here's a Dockerfile I used to create an image in an unsuccessful attempt to reproduce this issue...

FROM openjdk:latest

RUN curl -LO https://repo1.maven.org/maven2/org/hibernate/hibernate-core/3.5.0-Final/hibernate-core-3.5.0-Final.jar

Can you help point me in the right direction?

Side note: If this is an issue with identifying a package correctly in the first place, then this might be a bug in Syft instead of Grype.

enggabhishekshinde commented 3 years ago

Hi luhring, Please use following dockerfile. I'm thinking it's issue with syft because syft is not showing details in SBOM. I was not aware that grype is using syft's SBOM. Common collection is not getting reported by syft's SBOM. Do I need to raise new bug with syft's repo?..

Please find hibernate-core-3.5.0-final.jar file dependencies of following link. common collection is mentioned in compile dependencies. https://mvnrepository.com/artifact/org.hibernate/hibernate-core/3.5.0-Final

Dockerfile-

#Download base image ubuntu 20.04
FROM ubuntu:20.04

# Update Ubuntu Software repository
RUN apt update
RUN apt upgrade -y

RUN apt install -y openjdk-11-jdk maven curl
RUN curl -LO https://repo1.maven.org/maven2/org/hibernate/hibernate-core/3.5.0-Final/hibernate-core-3.5.0-Final.jar
luhring commented 3 years ago

Hi @enggabhishekshinde, no problem! I'll transfer the issue to Syft.

luhring commented 3 years ago

I'm wondering if Syft isn't reporting the "commons-collection" package because it isn't actually installed in this container image.

As you say, I do see commons-collections listed as a dependency in the file META-INF/maven/org.hibernate/hibernate-core/pom.xml within the JAR hibernate-core-3.5.0-Final.jar.

I think Grype is not scanning the jar embedded into jar

It seems like there might not be a "commons-collection" JAR within the "hibernate-core" JAR — at least not yet, perhaps a tool in the Java ecosystem would see the listed dependency and then install it? But right now, from what I can tell, the dependency is referenced, but not installed. And since it's not installed, it makes sense for Grype not to report any vulnerabilities based on that particular software.

Can you let me know if I'm looking at this correctly?

wlfshmn commented 3 years ago

I've had a look at the artifact question, as a Java developer. It does indeed not contain commons-collection. It has a compile-time (and transitively, runtime) scope dependency, through the hibernate parent on version 3.1, but syft has no way of understanding or resolving maven poms dependency graphs, given the amount of unbundled resources that would be required for such a feat.

I'm not sure why twistlock reports the vulnerability, but I'm leaning towards it being a false positive on their end if they infact identify it on hibernate-core, they should identify it on commons-collections. Any practical users of hibernate-core 3.5 will get commons-collections included in their container as well, and that one is affected by the vulnerability, but it is incorrect to on the binary level blaming it on hibernate-core. on the binary level the vulnerability is in commons-collections itself.

Creating an image that instead include common-collections 3.1 and syft will pick up the artifact correctly.

Grype however will not identify the vulnerability, because the CPE listed in the vulnerability cpe:2.3:a:apache:commons_collections:*:*:*:*:*:*:*:* does not match the syft-provided generated CPEs

"cpes": [
    "cpe:2.3:a:commons-collections:commons-collections:3.1:*:*:*:*:java:*:*",
    "cpe:2.3:a:commons-collections:commons-collections:3.1:*:*:*:*:maven:*:*",
    "cpe:2.3:a:*:commons-collections:3.1:*:*:*:*:java:*:*",
    "cpe:2.3:a:*:commons-collections:3.1:*:*:*:*:maven:*:*",
    "cpe:2.3:a:commons-collections:commons-collections:3.1:*:*:*:*:*:*:*",
    "cpe:2.3:a:*:commons-collections:3.1:*:*:*:*:*:*:*"
   ],

I'm no expert with grype or syft, but to me this looks like the CVE containing incorrect or too general data for syft to make the match, or that grype gives up before matching against the 6th CPE in the list due to the potential for vast amounts of false positives (and I've heard no end of tales about the quality of some of the CVE data). I suspect twistlock contains a hand-curated override list where this data is corrected so that the connection can be made, and I think it would be great if grype could make use of a data collection that has done this curation, such as oss-index (https://ossindex.sonatype.org/vuln/9b28a5d2-9be7-4414-a59b-98e25e4c608a?component-type=maven&component-name=commons-collections.commons-collections)

luhring commented 3 years ago

Hi @wlfshmn — thank you! This is very helpful.

So from this, I'm gathering two conclusions:

  1. The reported issue of Grype (via Syft) not finding the commons-collection package is resolved — and specifically, not considered a bug. This Syft issue is why I transferred the issue here, so I'm inclined to close this.

  2. There's a separate issue where our CPE matching (or really, CPE generation) is not working adequately enough to match commons-collection (when present) to CVE-2017-15708. I'm seeing that our generated CPEs are using commons-collections (with a dash), whereas the CVE's CPE has commons_collections (with an underscore), which is why none of our CPEs are matching.

For the latter issue, you're onto something when it comes to custom overrides. We're seeing a lot of false negatives particularly in the Java ecosystem. We're tracking this problem in https://github.com/anchore/grype/issues/192. And, we're thinking through a better way to handle CPEs in general (some details are included in comments in #317).

@wlfshmn would you be able to provide an updated Dockerfile that does install commons-collection? This would help us as we move forward with our CPE improvements and give us more data as we address https://github.com/anchore/grype/issues/192.

wlfshmn commented 3 years ago

Sure thing, It's just a matter of getting the file into any image really, so a Dockerfile like this weould do.

FROM alpine:3.13
RUN apk add --no-cache curl
RUN curl -LO https://repo1.maven.org/maven2/commons-collections/commons-collections/3.1/commons-collections-3.1.jar
luhring commented 3 years ago

Closing since Syft is correctly not finding the commons-collection package. See comments above for links to related, unresolved issues.