False positive OWASP-Findings

[profhenry]

We are using OWASP-Checks for detecting vulnerabilities.
We ran into some general problems with false positives because of some confusions regarding version numbers of the Equinox Platform and for example the contained OSGi Framework, please see here for a detailed explanation.

I am interested in your thoughts and possible solutions.

[merks]

I’m confused by exactly what the confusion is. Perhaps you can summarize and perhaps you have a suggestion, assuming it’s not just an OWASP bug that should be fixed there.

[laeubi]

@merks the problem is that the OWASP does claim there is a vulnerability in "4.x Eclipse" seem to apply it to everything including Equinox, and the bundle version of equinox is 3.x and therefore claimed to be vulnerable (even though it never was effected anyways).

[profhenry]

Some more details

My project is just using some parts of the Equinox Platform (mainly the Equinox OSGi Framework, Equinox CM/DS and Equinox Console...).
We are using OWASP in order to check for vulnerabilities using this maven plugin.
The check currently reports that

<dependency>
   <groupId>org.eclipse.platform</groupId>
   <artifactId>org.eclipse.osgi</artifactId>
   <version>3.18.100</version>
</dependency>

has the following CVEs

• CVE-2021-41033
• CVE-2020-27225
• CVE-2023-4218

I think these are all false positives. Maybe you could confirm this.

The used dependency check tool offers a global suppression list which is maintained by the developer/maintainer of the dependency check tool. There is a well defined process how the community can report false positives in order to get false positives on this list.

A request for these false positives were requested with

• [FP]: Wrongly reporting vulnerability CVE-2021-41033 on org.eclipse.osgi-3.18.0 jeremylong/DependencyCheck#5881
• [FP]: Wrongly reporting vulnerability CVE-2020-27225 on org.eclipse.osgi-3.18.0 jeremylong/DependencyCheck#5882

Short term it would be nice if you could pitch in and help to get these false positives accepted.

I think there is a general problem because these are not the first false positives of this kind.
@laeubi already stated the root of the problem.
I am thinking if there might be a possibility to address this problem in the long term (without having to manually request false positives).
I am not very optimistic if this is even possible because this depends heavily on the data filed with CVE (Known Affected Software).

So i am interested in your thoughts and also if other developers face the same problem.

[laeubi]

Basically it can only be addressed by the tool, assuming everything under one group Id having the same version and that it even matches a CVE that mentions a "management" not a release version is simply wrong.

And yes none of the CVEs apply to the Equinox OSGi Framework ...

[tjwatson]

For CVE-2023-4218 there is a related change in cfed903

That is available starting with org.eclipse.platform:org.eclipse.osgi:3.18.500

This does not affect the framework itself because it does no XML parsing. The change only put a safe-guard for others that use the XML parser service. Users of the service should be setting the correct options to the parser themselves, here we just were being secure by default.

[laeubi]

For CVE-2023-4218 there is a related change in cfed903
That is available starting with org.eclipse.platform:org.eclipse.osgi:3.18.500

Thanks for the reference, but defiantly not 4.29 as the tool suggests here, not sure if there will be an equinox 4 any time in the future ;-)

[tjwatson]

No, that is a general issue with the tool itself not understanding that there are multiple, independently versioned artifacts with each release of the Eclipse project overall. Nothing we can do for that here.

[laeubi]

Only thing would be to have one CVE per affected bundle... this sounds like a huge work but would bes reflect the actual impact, e.g as you explained only users of that parsing service might be affected....