CVE-2016-7051 in core, databind and annotations

Version 2.8.8

Discovered using OWASP Dependency Check: https://www.owasp.org/index.php/OWASP_Dependency_Check

CVE also exists in deprecated jackson-dataformat-cbor 2.6.6. I can’t seem to pull jackson-dataformats-binary:2.8.8 from Maven central to test if that triggers the CVE as well.

https://nvd.nist.gov/vuln/detail/CVE-2016-7051

Current workaround is to suppress CVE-2016-7051:

    <suppress>
        <notes><![CDATA[core, databind and annotations]]></notes>
        <gav regex="true">^com\.fasterxml\.jackson\.core:jackson-.*:2\.8\.8$</gav>
        <cve>CVE-2016-7051</cve>
    </suppress>
    <suppress>
        <notes><![CDATA[file name: jackson-dataformat-cbor-2.6.6.jar]]></notes>
        <gav>com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.6.6</gav>
        <cve>CVE-2016-7051</cve>
    </suppress>

[g1l3sp]

Hey cowtowncoder,

first off let me disclaim that I don’t know efenderbosch, I am not affiliated in any way with the OWASP Dependency Check tool, nor with anyone who is responsible for the CVE record mentioned above. I’m just another guy working in the code mines who is trying to appropriately mitigate a possible vulnerability in a project dependency. But I may have some helpful background for you based on doing a bit of footwork.

It appears to me this CVE, which was just published on April 14th (according to https://goo.gl/BAQtJh), refers to a vulnerability that was fixed back in September in this commit: https://github.com/FasterXML/jackson-dataformat-xml/commit/eeff2c312e9d4caa8c9f27b8f740c7529d00524a

The evidence for this is in the following bugzilla issue thread, comment 7, which responds to someone asking if this CVE is a duplicate of CVE-2016-3720 (https://bugzilla.redhat.com/show_bug.cgi?id=1378673#c7):

These 2 issues are distinct. The first issues was about XXE, and was fixed with the change in line 115 here:

https://github.com/FasterXML/jackson-dataformat-xml/blob/master/src/main/java/com/fasterxml/jackson/dataformat/xml/XmlFactory.java

The second issue was about DTD, and was fixed with the change in line 117.

Like efenderbosch above, the OWASP Dependency Check tool is registering a low confidence match in some of my projects against jackson-core and jackson-annotation based on the associated CPE (in this context you can think of this as coordinates to identify a computing system component) for CVE-2016-7051, which is cpe:/a:fasterxml:jackson:-. Crucially, this is the information that is used to match vulnerable components, and annoyingly, this CPE not only neglects to specify the module of Jackson involved, but it also fails to identify affected versions. Instead it gives - for the version, which I believe translates to “Not Applicable”.

In case you’re not familiar with OWASP Dependency Check, it’s a tool that (simplifying a bit) scans a software project, compares its dependencies against the National Vulnerability Database, and produces a report flagging any potential matches that might indicate vulnerable libraries. I’d speculate that the OWASP Dependency Check tool isn’t sure what to make of that “Not Applicable” designation, so to avoid not notifying some projects that are vulnerable (which would be the worst kind of failure for this type of tool), they are forced to over-notify based on this very vague CPE specification.

I don’t know how many projects use OWASP Dependency Check, but I’m guessing it’s quite a few, mine included (if it’s any indicator, there are Ant, Maven, Gradle, and Jenkins plugins for this tool). I’ll go out on a limb and suggest a course of action to avoid lots of people showing up on your virtual doorstep to ask about this same thing in the future:

1. Confirm the hypothesis that the referenced fix is indeed mitigation for ‘…server-side request forgery (SSRF) attacks via vectors related to a DTD’.
2. Verify which released versions of jackson-dataformat-xml contain the fix, and report that in this thread and wherever else inquirers will most easily find it without needing to bother you further.
3. Get in touch with someone with authority to modify CVE-2016-7051 and share this information about the specific module involved and the versions containing the fix (or inversely, the versions that are vulnerable, which is what the CPE should actually reflect). Hopefully they can change the CPE to something like cpe:/a:fasterxml:jackson_dataformat_xml:2.7.7 and all previous versions, which will give schmucks like me a clear idea that I can mitigate by simply upgrading to 2.7.8 or above.

Looking at the acknowledgement on the RedHat bugzilla, maybe this security researcher Adith Sudhakar (http://adithsudhakar.com/security/research/2016/06/04/cve/) is the right person to talk to, or at least can tell you who to contact to get that CVE updated.

EDIT: You can try this form to request the CVE be updated: https://cveform.mitre.org/ (as per https://cve.mitre.org/about/faqs.html#update_existing_information_in_cve_id)

Hopefully this info is helpful and not just an exercise in beating dead horses 😃

Cheers!

[cowtowncoder]

Update at:

https://nvd.nist.gov/vuln/detail/CVE-2016-7051#VulnChangeHistoryDiv

to indicate both that this is only for jackson-dataformat-xml, and fixed in 2.7.8 / 2.8.4