[FP]: CVE-2023-35116

[AB-xdev]

Package URl

pkg:maven/com.fasterxml.jackson.core/[email protected]

CPE

cpe:2.3:a:fasterxml:jackson-databind:2.15.2:::::::*

CVE

CVE-2023-35116

ODC Integration

{"label"=>"Maven Plugin"}

ODC Version

8.2.1

Description

As mentioned in FasterXML/jackson-databind#3972 CVE-2023-35116 is a FP.

The CVE is reported for all versions of the dependency.

The CVE is detected through https://central.sonatype.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.15.2/versions.

[github-actions]

Maven Coordinates

<dependency>
   <groupId>com.fasterxml.jackson.core</groupId>
   <artifactId>jackson-databind</artifactId>
   <version>2.15.2</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5779
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/com\.fasterxml\.jackson\.core/jackson-databind@.*$</packageUrl>
   <cpe>cpe:/a:fasterxml:jackson-databind</cpe>
</suppress>

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

[github-actions]

Maven Coordinates

<dependency>
   <groupId>com.fasterxml.jackson.core</groupId>
   <artifactId>jackson-databind</artifactId>
   <version>2.15.2</version>
</dependency>

Suppression rule:

<suppress base="true">
   <notes><![CDATA[
   FP per issue #5779
   ]]></notes>
   <packageUrl regex="true">^pkg:maven/com\.fasterxml\.jackson\.core/jackson-databind@.*$</packageUrl>
   <cpe>cpe:/a:fasterxml:jackson-databind</cpe>
</suppress>

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

[aikebah]

The finding by DC is not a false positive. The CVE is getting disputed in the tickets. Resolution should be with the vulnerability sources - OSSIndex and NVD (delisting it as improperly issued) and/or the CVE-issuer (to get it fully withdrawn).

Whether or not it is a vulnerability of the library is open for interpretation. From the ticket it is clear that chances for exploitability of it can be considered very low.

As an attacker you would need some other attack vector to coerce an application into the creation of a cyclic Map that you know to be subsequently serialized by Jackson. When you manage to do so you would be able to break the application on a StackOverflow, which could be classified as a vulnerability against the availability of the application.

Note: I agree with cowtowncoder that for similar effects within hashCode Map implementations in the JDK should also be considered vulnerable if the authorities in charge decide to not withdraw the CVE for this issue. Especially since the cyclic nature of the Map is explicitly allowed (though discouraged) in Map's Javadoc, with no mention whatsoever on the fatal consequences for hashCode ('no longer well-defined' is something else then 'calling the method is guaranteed to throw a StackOverflowException'):

While it is permissible for a map to contain itself as a value, extreme caution is advised: the equals and hashCode methods are no longer well defined on such a map

[CristianDuta]

The finding by DC is not a false positive. The CVE is getting disputed in the tickets. Resolution should be with the vulnerability sources - OSSIndex and NVD (delisting it as improperly issued) and/or the CVE-issuer (to get it fully withdrawn).

Whether or not it is a vulnerability of the library is open for interpretation. From the ticket it is clear that chances for exploitability of it can be considered very low.

As an attacker you would need some other attack vector to coerce an application into the creation of a cyclic Map that you know to be subsequently serialized by Jackson. When you manage to do so you would be able to break the application on a StackOverflow, which could be classified as a vulnerability against the availability of the application.

Note: I agree with cowtowncoder that for similar effects within hashCode Map implementations in the JDK should also be considered vulnerable if the authorities in charge decide to not withdraw the CVE for this issue. Especially since the cyclic nature of the Map is explicitly allowed (though discouraged) in Map's Javadoc, with no mention whatsoever on the fatal consequences for hashCode ('no longer well-defined' is something else then 'calling the method is guaranteed to throw a StackOverflowException'):

While it is permissible for a map to contain itself as a value, extreme caution is advised: the equals and hashCode methods are no longer well defined on such a map

My understanding of the issue:
The error occurs with any recursive data structure, and it's not a problem specific to the Jackson library. Jackson will not detect loops in data structures, but the same would be true if you were to call hashCode on the same map - this would also cause a stack overflow, but is not considered a security issue.
The original report did not provide a convincing demonstration of how the issue could be exploited for a Denial of Service (DoS) attack via a crafted string. The test case provided did not clearly demonstrate this possibility.
In Jackson 2.15, the default maximum nesting depth on the reader side is set at 1000 levels, and List / JsonNode deserializers both have non-JDK-stack based handling, which would prevent stack overflow issues.

That being said, although this might not be a cause for suppression, I would at least expect that they lower the severity level.

[AB-xdev]

The vulnerability is no longer listed on Sonatype's OSS INDEX.
https://ossindex.sonatype.org/component/pkg:maven/com.fasterxml.jackson.core/[email protected]

I think we can close this issue :)

[aikebah]

Thanks for pinging back on Sonatype's delisting @AB-xdev

Agree that it can be closed. Given the current state of the CVE and it's origins I don't expect it to resurface as an active CVE.

[pwagland]

This issue has started to show up again in our reports as of today. Sonatype still shows it as having no issues, but it is still turning up in our report.

[AB-xdev]

This issue has started to show up again in our reports as of today. Sonatype still shows it as having no issues, but it is still turning up in our report.

→ FasterXML/jackson-databind#3972 (comment)

TL;DR
People at NIST can't read issues.

[hannes-angst]

I am unsure, but It looks like the suppression is too broad. There is no version that gets suppressed nor a specific CVE. Will this not suppress just any issue with jackson-databind?

This one does a CVE-2023-35116 specific suppression.

   <suppress>
        <notes><![CDATA[
   FP per issue #5779
   ]]></notes>
        <packageUrl regex="true">^pkg:maven/com\.fasterxml\.jackson\.core/jackson-databind@.*$</packageUrl>
        <cve>CVE-2023-35116</cve>
    </suppress>

[aikebah]

@hannes-angst The suppression generated by our automation is indeed too broad for this FP report.

Most FP reports are about incorrectly identified libraries (wrong CPE), that's why our automation for FP reports proposes a COE suppression.

There is automation in place that allows the us as maintainers to quickly process that kind of FP reports into the hostedSuppressions file.

[aikebah]

This issue has started to show up again in our reports as of today. Sonatype still shows it as having no issues, but it is still turning up in our report.

→ FasterXML/jackson-databind#3972 (comment)

TL;DR People at NIST can't read issues.

Have kindly requested the people at NIST to re-read the references in an attempt to also get this de-listed at NVD.

[aikebah]

This issue has started to show up again in our reports as of today. Sonatype still shows it as having no issues, but it is still turning up in our report.

→ FasterXML/jackson-databind#3972 (comment)
TL;DR People at NIST can't read issues.

Have kindly requested the people at NIST to re-read the references in an attempt to also get this de-listed at NVD.

Unfortunately didn't manage to convince them to completely remove it, but at least they lowered the CVSS score significantly.

[josebarros2025]

Still happens please let me know if there are any fix for this

[aikebah]

@josebarroszeiss The possible fixes are suppressing it yourself, convincing the NIST that it should be delisted from the NVD or convincing the requester of the CVE to withdraw it.