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);
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.
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.
This problem was assigned following vuln id: CVE-2020-25649
Update: backported in potential future versions:
(in addition to being included in 2.11.0 and later)
@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?
@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.
@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?
@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.
@cowtowncoder now that 2.12.0 is out, when can we expect 2.10.5.1? Apologies if this is already being considered.
Yes, #2920 is on my todo list after blogging about 2.12.0 release.
Updated notes above: now fix included in:
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?
@melloware It was always fixed in 2.11.0, and as a consequence also fixed in 2.12.0. I have no idea what Sonatype or other security vendors do; they probably need to update something in their cve databases.
I only get to contribute my free labor to support their core business.
Thank you
@cowtowncoder no jackson-bom bump to 2.10.5.1?
Edit: I did find 2.10.5.20201202 in Maven Central. Will go with it unless you tell me that there is another BOM version planned to include this patch.
@cowtowncoder no jackson-bom bump to
2.10.5.1?Edit: I did find
2.10.5.20201202in Maven Central. Will go with it unless you tell me that there is another BOM version planned to include this patch.
2.10.5.20201202 includes databind bump to 2.10.5.1
Correct: micro-patches are not complete sets so there would not be 2.10.5.1 of jackson-bom; instead, timestamp-style version is used as @aakarshsingh pointed out. So 2.10.5.20201202 is the correct answer here.
Updated notes above: now fix included in:
- 2.10.5.1
There appears to be no published version 2.10.5.1 yet.
https://search.maven.org/artifact/com.fasterxml.jackson.core/jackson-annotations
Is there an update on when this fix will be made available?
@traviscollins Micro-patches -- ones with fourth digit -- are always for just one single artifact: in this case jackson-databind. They are not full patch releases. There is usually a matching jackson-bom release, however; in this case 2.10.5.20201202 (as per https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.10)
So there will not be jackson-annotations 2.10.5.1 released.
Recommended mechanism to add dependencies with micro-patches is either to start with default version (2.10.5) for other components, override one, or to use jackson-bom mentioned above.
Nice
Note: The CVE-2020-25649 does list 2.10.5.1 as "excluded" but the associated CPE has a 2.10.5...* associated with it so it still flags the fixed version as an issue in some security scanning tools.
I submitted a CVE request with mitre.org but thought I'd highlight here in case others are running into similar challenges and doing the same research I spent a couple hours chasing down.
Sorry to comment on a closed issue. :(
@fdevans Thank you for noting this -- perfectly reasonable to report on relevant issue for case like this.
Most helpful comment
@melloware It was always fixed in 2.11.0, and as a consequence also fixed in 2.12.0. I have no idea what Sonatype or other security vendors do; they probably need to update something in their cve databases.
I only get to contribute my free labor to support their core business.