[FP]: xercesImpl-2.12.2.jar matched for CVE-2017-10355

[melo0187]

Package URl

pkg:maven/xerces/xercesImpl@2.12.2

CPE

cpe:2.3:a:apache:xerces-j:2.12.2:*:*:*:*:*:*:*

CVE

CVE-2017-10355

ODC Integration

{"label"=>"Gradle Plugin"}

ODC Version

7.1.1

Description

I can't see why the pkg matches with the CVE. The CVE's entry on nvd.nist.gov doesn't even mention the reported cpe. Package and CVE look unrelated to me.

[github-actions[bot]]

Maven Coordinates

<dependency>
   <groupId>xerces</groupId>
   <artifactId>xercesImpl</artifactId>
   <version>2.12.2</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #4614
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/xerces/xercesImpl@.*$</packageUrl>
   <cpe>cpe:/a:apache:xerces-j</cpe>
</suppress>

Link to test results: https://github.com/jeremylong/DependencyCheck/actions/runs/2527559089

[aikebah]

It's plain and clear from the report: CVE-2017-10355 (OSSINDEX)

Which is to say: the intelligence that this CVE (still) applies to version 2.12.2 comes from the security analysts of Sonatype OSSINDEX, not from the NVD datastreams. So it may differ from the listing at the NVD.

Up to now OSSINDEX has provided sensible reasoning that CVEs still apply to versions of the library not listed in the NVD as the fix was either documentation to not use certain coding patterns, or a mere deprecation instead of removal of the vulnerable code. Both of which require human judgement of the code usage of a project to determine whether or not for your specific use of the library the vulnerability is mitigated or not, as the vulnerability is still lurking in the codebase.

I expect this one to be similar in nature.

[jeremylong]

Has anyone contacted the OSS Index team regarding this?

This differs greatly from the CVE: https://ossindex.sonatype.org/vulnerability/sonatype-2017-0348?component-type=maven&component-name=xerces%2FxercesImpl&utm_source=dependency-check&utm_medium=integration&utm_content=7.1.1

[kwwall]

@jeremylong - as noted in an email, I also checked Sonatype's flagship SCA project Nexus IQ, for this CVE and Nexus IQ is pointing to the NVD CVE and not their own OSS Index CVE. That seems a bit curious. Tomorrow I will see if I can get it to scan AntiSamy and see if it flags xercesImpl or not. I have not seen Snyk flagging this though. @davewichers - Do you have GitHub's Dependabot enabled? If so, does that flag this?

[kwwall]

Update: While Nexus IQ refers to the NVD CVE for it's description, they do report the vulnerability consistent in a manner with OSS Index and but the Nexus IQ description of the reported vulnerability has a different (and someone more useful) description that what is used for the OSS Index description. Specifically, the Nexus IQ vulnerability description mentions the root cause of the problem being that the XMLEntityManager.setupCurrentEntity() method lacks a timeout mechanism. (I will say no more for concern about possible copyright infringement, but most likely this information was in the now defunct, original blog post previously at https://blogs.securiteam.com/index.php/archives/3271.) However, that may be enough information to provide additional evidence for your management that is a false positive. That certainly seems to be the case with OWASP AntiSamy.

[albertwangnz]

Hi @kwwall is there a further update about the FP? Do we know the reason that xerceslmpl-2.12.2.jar is matched with the CVE-2017-10355? Thank you.

[kwwall]

Have heard nothing further. I think we need to report it to Sonatype for at least their OSS Index project. Sonatype Lift also reports this for AntiSamy 1.7.0, but I think that's because Lift uses OSS index as on of its vulnerability sources.

On Thu, Jul 28, 2022, 10:12 PM Albert Wang @.***> wrote:

Hi @kwwall https://github.com/kwwall is there a further update about the FP? Do we know the reason that xerceslmpl-2.12.2.jar is matched with the CVE-2017-10355 https://github.com/advisories/GHSA-c7m6-53c4-386j? Thank you.

— Reply to this email directly, view it on GitHub https://github.com/jeremylong/DependencyCheck/issues/4614#issuecomment-1198809131, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PGYVZUDEYMG2P56QSGTVWM4Z5ANCNFSM5ZIA37EA . You are receiving this because you were mentioned.Message ID: @.***>

[albertylw]

Hi @kwwall thank you for your kind reply. I am not familiar with where to report it. Do you think if we should create an issue on https://github.com/sonatype/ossindex-public?

Albert

[kwwall]

Probably not. I think that site is just implements a web API and client that accesses the information in https://ossindex.sonatype.org/. I think it is flawed data in ossindex.sonatype.com that needs reported. I've not signed up for that site to see where/ how to report bugs because I have a dozen more pressing matters at the moment. If you find out how / where to report bugs, I will gladly do so though.

On Thu, Jul 28, 2022, 11:48 PM albertylw @.***> wrote:

Hi @kwwall https://github.com/kwwall thank you for your kind reply. I am not familiar with where to report it. Do you think if we should create an issue on https://github.com/sonatype/ossindex-public?

Albert

— Reply to this email directly, view it on GitHub https://github.com/jeremylong/DependencyCheck/issues/4614#issuecomment-1198850516, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PG2YSZLTBZ53H3RMKZDVWNIA7ANCNFSM5ZIA37EA . You are receiving this because you were mentioned.Message ID: @.***>

[aikebah]

The proper issue-tracking to report issues on OSSIndex entries is https://github.com/OSSIndex/vulns

[albertylw]

The proper issue-tracking to report issues on OSSIndex entries is https://github.com/OSSIndex/vulns

Thank you, @aikebah

[albertylw]

Probably not. I think that site is just implements a web API and client that accesses the information in https://ossindex.sonatype.org/. I think it is flawed data in ossindex.sonatype.com that needs reported. I've not signed up for that site to see where/ how to report bugs because I have a dozen more pressing matters at the moment. If you find out how / where to report bugs, I will gladly do so though. … On Thu, Jul 28, 2022, 11:48 PM albertylw @.> wrote: Hi @kwwall https://github.com/kwwall thank you for your kind reply. I am not familiar with where to report it. Do you think if we should create an issue on https://github.com/sonatype/ossindex-public? Albert — Reply to this email directly, view it on GitHub <#4614 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAO6PG2YSZLTBZ53H3RMKZDVWNIA7ANCNFSM5ZIA37EA . You are receiving this because you were mentioned.Message ID: @.>

I will try. Thank you.

[albertwangnz]

@kwwall @aikebah I reported the issue to OSSIndex.

My current understanding is that OSSIndex published a vulnerability [sonatype-2017-0348] CWE-833: Deadlock of xerces:xercesImpl.

Somehow, when OWASP Dependency-Check reports the vulnerability, it uses another title CVE-2017-10355 (OSSINDEX). However, CVE-2017-10355 looks like a totally different vulnerability.

Therefore, xerces:xercesImpl may have the vulnerability, but it is not CVE-2017-10355.

I didn't find any information about the vulnerability on xerces.apache.org/xerces2-j or xerces.apache.org/xerces2-j/releases.html.

I will email Apache Software Foundation j-dev@xerces.apache.org for help.

Thank you.

Albert

[aikebah]

@albertwangnz The CVE 2017 10355 is a vulnerability that OSSINDEX themselves returns on the API call as applicable for the xercesImpl library.

The sonatype 2017 0348 is hidden to dependency-check based on filtering that is still in place as initially there were Exceptions resulting from the data of the internal sonatype vulnerabilities (see https://github.com/jeremylong/DependencyCheck/issues/4527#issuecomment-1136715391)

So these two are indeed completely separate issues, but according to OSSINDEX data xercesImpl is subject to CVE 2017 10355.

[albertylw]

@albertwangnz The CVE 2017 10355 is a vulnerability that OSSINDEX themselves returns on the API call as applicable for the xercesImpl library.

The sonatype 2017 0348 is hidden to dependency-check based on filtering that is still in place as initially there were Exceptions resulting from the data of the internal sonatype vulnerabilities (see #4527 (comment))

So these two are indeed completely separate issues, but according to OSSINDEX data xercesImpl is subject to CVE 2017 10355.

Hi @aikebah , so sounds like OSSINDEX should not return CVE 2017 10355 as applicable for the xercelmpl library. Hope OSSINDEX could view the BUG I raised.

Thank you.

[aikebah]

After closely re-reading the report I spotted that both the internal Sonatype issue name and the CVE referenced in this ticket stem from the same reported issue... so I checked the OSSIndex cache of dependency-check (after an initial cleanup), harvested the sonatype OSSINDEX API response for XercesImpl from it and added the info to the OSSINDEX ticket.

The vulnerability of XercesImpl is sonatype-2017-0348, the CVE number is a false flag

[aikebah]

Update: SNYK also relates the issue to the same CVE...

https://security.snyk.io/vuln/SNYK-JAVA-XERCES-31497

looks like in some way opening an FTP connection by XercesImpl is involved

They appear to differ opinion on which versions of XercesImpl are affected and which CWE is violated (the Snyk entry indicates that 2.11.0 is patched for it and links the issue to CWE-400)

[aikebah]

What I can digest from the SNYK references I would say that the issue indeed was never resolved within Xerces itself (still fully relying on Java defaults to provide sensible timeouts), but it's only resolved because the JDK has built in a default timeout for FTP connections in response to the CVE, so that over time the connections will time out and release the hanging thread with a timeout exception. In my view this default timeout is still large enough to warrant OSSINDEX security team to keep the issue for Xerces open (with a 300k millisec timeout an attacker may well be capable of triggering at least a significant service degradation).

[albertylw]

Hi @aikebah, you are awesome! I think the situation is more clear now.

[albertwangnz]

Hi @aikebah , do you think SNYK-JAVA-XERCES-31497 and sonatype-2017-0348 are the same issue of XercesImpl, or they are different issues?

[aikebah]

They both link to https://blogs.securiteam.com/index.php/archives/3271 in the references, so yes, I consider them as the same issue. The exploitdb entry linked at Snyk indicates that in one go a vulnerability was reported for both the JDK and Apache Xerces, however it only indicates a vendor response from Oracle, so I don't know whether this was ever raised by the reporters to the apache xerces team at the time (likely not, or their response would've been included I would say). Oracle apparently decided to implement a 5min default timeout in the JDK as mitigation of the reported vulnerability/ies and assigned the CVE.

[davewichers]

I do have dependabot enabled. But it is not flagging this. When I run:

mvn org.owasp:dependency-check-maven:check

It flags xercesImpl.

-Dave

On Mon, Jul 18, 2022 at 10:30 PM Kevin W. Wall @.***> wrote:

@jeremylong https://github.com/jeremylong - as noted in an email, I also checked Sonatype's flagship SCA project Nexus IQ, for this CVE and Nexus IQ is pointing to the NVD CVE and not their own OSS Index CVE. That seems a bit curious. Tomorrow I will see if I can get it to scan AntiSamy and see if it flags xercesImpl or not. I have not seen Snyk flagging this though. @davewichers https://github.com/davewichers - Do you have GitHub's Dependabot enabled? If so, does that flag this?

— Reply to this email directly, view it on GitHub https://github.com/jeremylong/DependencyCheck/issues/4614#issuecomment-1188526988, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGFWBKPFL3OE2QHZ2NJDXDVUYHM7ANCNFSM5ZIA37EA . You are receiving this because you were mentioned.Message ID: @.***>