DOMDeserializer: setExpandEntityReferences(false) may not prevent external entity expansion in all cases [CVE-2020-25649]

[baranowb]

As per description:
https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/ext/DOMDeserializer.java#L30
and
https://github.com/FasterXML/jackson-databind/blob/master/src/main/java/com/fasterxml/jackson/databind/ext/DOMDeserializer.java#L33

is not enough to stop expansion of entities. Depending on provider(xerces) being used it might work with current DOMDeserializer or not. If JDK default is used(at least one that I used at time of test), it wont allow to expand entities, however, if other provider from classpath is used it might, for instance, xerces-2.12.... does allow( iirc) expansion.

Reference: https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#jaxp-documentbuilderfactory-saxparserfactory-and-dom4j

I tinkered a bit with databind classes and I had something like:

factory.setValidating(true);
factory.setExpandEntityReferences(false);
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

[cowtowncoder]

First of all, thank you for reporting this security concern.

One quick note/question: you should not enable validation, since that would basically require expansion -- you can not do that, and it is not something Jackson itself sets.
I wonder if that is a requirement for problem to occur?

Aside from that, I'll see if adding missing settings from the list of 3 mentioned is safe wrt JDK baselines Jackson expects.

[cowtowncoder]

Ok so specifically while other 2 settings are already applied, this could be added:

factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

It is not entirely risk-free change, actually, since it does not only block entity expansion that we want, but also outlaws use of DOCTYPE declaration which theoretically could cause issues for someone.
For that reason this will need to go in 2.11, not 2.10 patch.

One more setting that could be considered, from the linked-to page, would be:

factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

which I'll probably add too.

[cowtowncoder]

This problem was assigned following vuln id: CVE-2020-25649

[cowtowncoder]

Update: backported in potential future versions:

• 2.6.7.4 (released 25-Oct-2020)
• 2.9.10.7 (released 02-Dec-2020)
• 2.10.5.1 (released 02-Dec-2020)

(in addition to being included in 2.11.0 and later)

[nloke]

@cowtowncoder
I saw the code being backported to 2.10.6 and we needed that for this CVE. Do you know when will 2.10.6 be released?

[cowtowncoder]

@nloke No immediate plan; it might be that no full 2.10.6 will be released but 2.10.5.1 for databind. And if so, would probably want to do around same time as 2.9.10.7 (the last micro-patch for 2.9, as 2.9 goes EOL by end of 2020).
So depending a bit on all around progress, either towards end of November or in December.

[sourabhsparkala]

@nloke No immediate plan; it might be that no full 2.10.6 will be released but 2.10.5.1 for databind. And if so, would probably want to do around same time as 2.9.10.7 (the last micro-patch for 2.9, as 2.9 goes EOL by end of 2020).
So depending a bit on all around progress, either towards end of November or in December.

Hello, is there a planned date for 2.10.6 or 2.10.5.1 with the above fix?

[cowtowncoder]

@sourabhsparkala due to variability in time I have for development and all related tasks, I typically do not set out dates for various releases. This is relatively low priority thing for me because it's just a single fix and while there's cve id registered it seems unlikely to be exploitable by anybody.

But I will go ahead and create a separate issue for that micro-patch so I won't forget. Maybe I'll get patch out by November -- main limitation is that I will not want to release any more versions of 2.10.x and after this patch will probably close 2.10 branch for good. 2.11.x has been out for a while, and 2.12.0 should be out in November.
I think 2.10.5.1 will be released right after 2.12.0.

[radarsh]

@cowtowncoder now that 2.12.0 is out, when can we expect 2.10.5.1? Apologies if this is already being considered.

[cowtowncoder]

Yes, #2920 is on my todo list after blogging about 2.12.0 release.

[cowtowncoder]

Updated notes above: now fix included in:

• 2.6.7.4
• 2.9.10.7
• 2.10.5.1
• 2.11.0 and later

[melloware]

I am confused is this fixed in 2.11.0 or 2.12.0? Because Sonatype is reporting this as a security vulnerability in 2.11.0 still?