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.

[g1l3sp]

Hi @jeremylong,

I guess I really should take your word for it on that. As the author of OWASP Dependency Check, you know for certain how it is interpreting CPEs. And I can clearly see the merit of treating "NA" as equivalent to "ANY" when you are trying to identify vulnerable libraries and want to avoid those dreaded false negatives. That being said, the CPE naming specification, which I will admit to having read (partially at least -- and I'll provide links below), specifically gives "-" the meaning "not applicable":

From page 18 of the CPE 2.3 naming spec:

6.1.2.1.1 Handling logical values
The logical values ANY and NA are defined as possible attribute values in WFNs. The logical value
ANY SHALL bind to what [CPE22] calls a “blank” (i.e., an empty component, indicated by two
sequential colons) in the URI. The logical value NA SHALL bind to a single hyphen.

And additionally here's a bit of the pseudocode for binding a well formed CPE name to a URI from page 20 of the same 2.3 spec:

function bind_value_for_URI(s)
   ;; Takes a string s and converts it to the proper string for
   ;; inclusion in a CPE v2.2-conformant URI. The logical value ANY
   ;; binds to the blank in the 2.2-conformant URI.
   if s = ANY then return("").
   ;; The value NA binds to a single hyphen.
   if s = NA then return("-").
   ;; If we get here, we’re dealing with a string value.
   return transform_for_uri(s).
end.

The 2.2 version of the CPE specification states it similarly, though there is also a bit of text to support your semantic interpretation:

It is often necessary to use a CPE Name when identifying a specific release of a given platform.
If attempting to create a CPE Name for this, and a specific component is not applicable to the
given platform, then the term '-' should be used. Note that use of the '-' term is different than
leaving the component blank, even though in practice both options might identify with the same
set of platform types. For example, an application may not have different editions. A CPE
Name for such an application may use the '-' term for the edition component.

So from an annoyingly precise point of view, the meaning of "-" is different than a blank. But practically speaking, I think you are on solid ground treating blank and dash equivalently.

I realize I've been painfully pedantic about this, and for that I apologize. Let me just add a big "THANK YOU!!" for the wonderful OWASP Dependency Check tool. I am a big advocate for its use at my workplace, and wherever else I find myself talking devops or application security. That it is freely available, open source, and so easy to integrate is pure awesome sauce, and I have no doubt that in this age of constant breach notifications, its usage has prevented an untold many more from occurring.

Cheers!

References:

• Common Platform Enumeration: Naming Specification Version 2.3: http://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf
• Common Platform Enumeration Specification Version 2.2 (rc): https://cpe.mitre.org/files/cpe-specification_2.2.pdf

[jeremylong]

Correct, and I spoke out of what is actually done with the NVD data using the 2.2 schema. When we move to the NVD JSON data feed (which contains the 2.3 CPEs) we will likely update the processing to correctly match using the 2.3 spec. The issue is of course the 2.2 spec and in practice the dash is used commonly as meaning all/any.

…

--Jeremy

On Tue, Jun 20, 2017 at 12:45 PM, g1l3sp ***@***.***> wrote: Hi @jeremylong <https://github.com/jeremylong>, I guess I really should take your word for it on that. As the author of OWASP Dependency Check, you know for certain how *it* is interpreting CPEs. And I can clearly see the merit of treating "NA" as equivalent to "ANY" when you are trying to identify vulnerable libraries and want to avoid those dreaded false negatives. That being said, the CPE naming specification, which I will admit to having read (partially at least -- and I'll provide links below), specifically gives "-" the meaning "not applicable": From page 18 of the CPE 2.3 naming spec: 6.1.2.1.1 Handling logical values The logical values ANY and NA are defined as possible attribute values in WFNs. The logical value ANY SHALL bind to what [CPE22] calls a “blank” (i.e., an empty component, indicated by two sequential colons) in the URI. The logical value NA SHALL bind to a single *hyphen.* And additionally here's a bit of the pseudocode for binding a well formed CPE name to a URI from page 20 of the same 2.3 spec: function bind_value_for_URI(s) ;; Takes a string s and converts it to the proper string for ;; inclusion in a CPE v2.2-conformant URI. The logical value ANY ;; binds to the blank in the 2.2-conformant URI. if s = ANY then return(""). ;; The value NA binds to a single hyphen. if s = NA then return("-"). ;; If we get here, we’re dealing with a string value. return transform_for_uri(s). end. The 2.2 version of the CPE specification states it similarly, though there is also a bit of text to support your semantic interpretation: It is often necessary to use a CPE Name when identifying a specific release of a given platform. If attempting to create a CPE Name for this, and a specific component is not applicable to the given platform, then the term '-' should be used. Note that use of the '-' term is different than leaving the component blank, even though in practice both options might identify with the same set of platform types. For example, an application may not have different editions. A CPE Name for such an application may use the '-' term for the edition component. So from an annoyingly precise point of view, the meaning of "-" is different than a blank. But practically speaking, I think you are on solid ground treating blank and dash equivalently. I realize I've been painfully pedantic about this, and for that I apologize. Let me just add a big "THANK YOU!!" for the wonderful OWASP Dependency Check tool. I am a big advocate for its use at my workplace, and wherever else I find myself talking devops or application security. That it is freely available, open source, and so easy to integrate is pure awesome sauce, and I have no doubt that in this age of constant breach notifications, its usage has prevented an untold many more from occurring. Cheers! References: - Common Platform Enumeration: Naming Specification Version 2.3: http://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf <http://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7695.pdf> - Common Platform Enumeration Specification Version 2.2 (rc): https://cpe.mitre.org/files/cpe-specification_2.2.pdf <https://cpe.mitre.org/files/cpe-specification_2.2.pdf> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#371 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA0qwlosa_EgAtOS0w8IJ9VS9hgiLJZ_ks5sF_c7gaJpZM4NH_Sr> .