CVE-2016-7051 in core, databind and annotations

[efenderbosch]

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>

[cowtowncoder]

Please explain the assumed problem to some degree instead of adding links and making me try to decipher intended issue. There are many, many issues being reported, and vague ones have low chance of being worked on.

[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: FasterXML/jackson-dataformat-xml@eeff2c3

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]

@g1l3sp Excellent, thank you for including more information. I am only tangentially familiar with systems involved (enough to have guesses wrt xml aspects -- although those aspects I am historically quite aware of, although reports seem to come in waves... million lols vuln has been known since late -90s probably :) ), so this is good stuff.

I tried contacting people wrt Red Hat CVE but that seems to be bit of low-yield work, and complicated by odd division of labor and responsibilities; basically it seems many somewhat independent and loosely connected entities (which usually is actually a good thing...), in this case resulting in quite disparate work and esp. lack of update on what changes.

I do think that this could be useful thing for planned "Jackson security module" project. Authors of that project would hopefully be better connected to infosec community, to effectively guide these efforts. I don't think amount of work would be huge, if one knew right people and working relationship. It just takes time and effort to cultivate those; and interest in the domain.

[cowtowncoder]

@efenderbosch For what it is worth, based onb @g1l3sp 's excellent summary, this is due to:

FasterXML/jackson-dataformat-xml#211

and fix included thereby in jackson-dataformat-xml module versions 2.7.8 and 2.8.4.
2.8.8 should not be affected, at least to the original reported issue.

But I do not think this can affect CBOR module in any way, shape or form: it does not use XML for anything.

[g1l3sp]

@cowtowncoder, thank you for confirming the fixed versions. In case it got lost in the shuffle of my edits to the above, you can use this form to request an update to the CVE:

https://cveform.mitre.org/ (as per https://cve.mitre.org/about/faqs.html#update_existing_information_in_cve_id)

My guess is that the wheels will turn slowly, but that doing so should eventually get the CVE updated so that it will not trigger these false positives.

[efenderbosch]

Thanks @g1l3sp for all the extra details and apologies to @cowtowncoder for the initial lack of details.

[cowtowncoder]

Thank you everyone for additional information. And if anyone has bandwidth to help here (wrt external updates), such help would be very much appreciated.

[cowtowncoder]

I sent an update request to indicate fixed-in version (2.7.8), and indicate that if possible, it'd be good to limit scope -- this only affects XML processing component. But I do not know if and how latter can be done, as I am not familiar with how they model software components.
I hope version information itself can help, although even there things can be bit complicated (fix is in 2.8.4 as well, but since Jackson does keep multiple branches open it's not a simple question of "bigger version number"). Still, it's better to have some version information, even if complete, as well as link to the issue (FasterXML/jackson-dataformat-xml#211) for more information.

[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

[jeremylong]

@g1l3sp To clarify one statement you made earlier in this thread " Instead it gives - for the version, which I believe translates to "Not Applicable"." Actually, the - means all versions are affected.