Bug: Incorrect vulnerability details for Google Guava

[wjglerum]

Vulnerability URL
https://ossindex.sonatype.org/vulnerability/sonatype-2020-0926?component-type=maven&component-name=com.google.guava/guava

Component URL
https://ossindex.sonatype.org/component/pkg:maven/com.google.guava/guava@31.1-jre

Description
After the db update, this is now reporting again for recent versions, I think this is by mistake?

Also see:

• guava fail guava 31.1-re, false positive? sonatype/ossindex-maven#76
• CVE-2020-8908: Files::createTempDir local information disclosure vulnerability google/guava#4011

[msymons]

Reading the guava github issue, I think that it is correct to have a sonatype issue id to match against versions after 29.0. However, I do think that things need to be clarified as OSSI used to match a purl such as pkg:maven/com.google.guava/guava@27.1-jre against CVE-2020-8908 but now no longer does so.

This CVE is mentioned in the description of sonatype-2020-0926 but I find it confusing.

I also observe that sonatype-2020-0926 is linked to CWE-379 (Creation of Temporary File in Directory with Insecure Permissions) which seems correct. But CVE-2020-8908 is linked to CWE-173 & CWE-200 & CWE-732

So, is the implication of sonatype-2020-0926 that "Sonatype research has given a better representation of the weakness" and of versions affected than the original CVE

Or is that OSSI data cannot handle vulnerabilities with multiple CWE?

Or is it both? Or something else?

Bottom line... an improvement in the sonatype-2020-0926 description would really help.

[ken-duck]

Having moved from the original OSS Index database to the new database and infrastructure there have been a number of side effects. The vulnerability data should be MUCH better with far fewer false positives and false negatives. Vulnerabilities may also be reported by OSS Index before the CVE or its details have been defined. These are assigned "sonatype-####-####" IDs (as well as anything that doesn't have a CVE).

However, I do not currently have a way to reliably get the CVE for a Sonatype* vulnerability once it has been assigned, though our researchers are aware they exist. I am in discussions with them to try and get that data, but I do not yet have a timeline.

The bottom line being, this is indeed a valid vulnerability as mentioned by @msymons .

I will take the other feedback from this thread and put it into our internal tracking system and see if we can't make some more improvements based on your help.

[ken-duck]

Just to let you know. One of the initiatives we have undertaken is to provide a better description for issues (for folks who have an OSSI account). This will likely be released in the next 2-3 weeks (we have an infrastructure upgrade at the same time, so I cannot be more precise -- depends on how well our rollout to staging/prod goes).