Deserialization vulnerability via polymorphic deserialization (CVE-2017-7525)

[jwedel]

There is this vulnerability (CVE-2017-7525, https://bugzilla.redhat.com/show_bug.cgi?id=1462702) in jackson-databind that allows remote code execution.

I tried to check existing issues but could not find anything related.

This vulnerability has been reported in 2.8.9 as well as all pre releases of 2.9.0. Is this actually fixed in 2.9.0 or is there a patch release planned?

[jwedel]

More information about the vulnerability and possible exploits can be found in this paper:
https://www.github.com/mbechler/marshalsec/blob/master/marshalsec.pdf?raw=true

See chapter 3.1.6.

[cowtowncoder]

The issue was reported as #1599 a while ago, and fixed for 2.8.9 and 2.9.0; plus backported in 2.7.9.1 and 2.6.7.1.
Also note #1680 for further inclusion of com.sun.rowset.JdbcRowSetImpl, addressing one issue remaining after 1599 fix (included in upcoming 2.8.10, and 2.9.0).

More work is probably needed to refine set of classes blocked: about 10 or so are blacklisted, based on reports of known vulnerabilities.

[jwedel]

Hi @cowtowncoder, thanks for your reply.

This vulnerability has been reported in 2.8.9 as well as all pre releases of 2.9.0.

We are using automated vulnerability scan from Sonatype called CLM. From last wednesday on, it also reported the same vulnerability also for the newer versions (see quote above). This is probably due to the black listing approach. I don't have any reference that explains exploits for those versions but I assumed that you guys probably already know.

[cowtowncoder]

@jwedel it is also possible that whoever entered data into system did not know, perhaps since fix predates creation of CVE.

It is also unfortunate that there is no real way to indicate the fact that vulnerability requires active acts by users of the library -- without either explicitly enabling "default typing" or explicitly annotating an Object-valued property to use classname-based polymorphic typing -- which is one key consideration. One possible interpretation is that there is no way to "fix" this short of removing feature itself as use of white-listing is unlikely to make much sense for usage (users who want to limit what classes this should work on should not even use classname as id at all, but type name.

Re-reading the paper to look for other classes that should be blacklisted: all JDK-included types for which exploits reported are handled (as far as I can see), but there seem to be some from common frameworks/libs that are not.
But one exploit listed (com.sun.rowset.JdbcRowSetImpl) was actually blocked as per #1680.

[jwedel]

@cowtowncoder hi, I've checked the source: National Vulnerability Database
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-7525

However, as you may have tried youself, this link is a dead end. I tried to seach for the CVE and couldn't find anything. Maybe the NVD revoked that?

[cowtowncoder]

@jwedel Hmmh. Well that is interesting. Bit difficult to add more information or notes for non-public entry. :-/

[jwedel]

@cowtowncoder Sonatype is currently checking their database to find out if it's a false positive: https://issues.sonatype.org/browse/CLMDATA-4117

You need an account to view the issue.

[cowtowncoder]

@jwedel I do have an account, but I don't seem to have access. Account id same as my handle here.

[cowtowncoder]

After reviewing the document, I think there are 5 potential problem remaining: 4.8, 4.9, 4.10, 4.12 and 4.21. Of these, 4.9 seems severe, others not necessarily of much threat (like 4.21). All of these require existence of certain libs beyond JDK (unlike types blocked so far), but they are common enough to be of concern. Will need to figured out fully-qualified classnames, can then add to blacklist.

[jwedel]

Hi @cowtowncoder,

For the documentation puposes, those vulnerabilites are potentially applicable if you have the following libraries on your classpath:

• 4.8: c3p0
• 4.9: c3p0
• 4.10: spring-beans and spring-context
• 4.12: spring-aop
• 4.21: JDK

So 4.10 and 4.12 is very common for modern spring applications, especially spring boot.

Two things I want to clarify:

First, which versions of jackson are affected by those potential problems you mentioned? I guess it's 2.8.9 as well as 2.9.0? Are you actually planning to fix that somehow?

Second, Redhat actually claimed that they "fixed" it ( See here) although they did not tell how and I don't see any commits linked. Do you have any idea how they did fix it?

[cowtowncoder]

@jwedel Thank you, yes, those are the libraries. Issue I added for remaining types is #1737, and will be in 2.8.10 and 2.9.1 wrt types other than JdbcRowSetImpl (and Xalan transformer impl) that were included earlier in 2.8.9 / 2.9.0.

As to Red Hat, two main possibilities I think: either (a) they were referring to #1599 (adding mechanism to prevent issues and blocking first 2 reported types) or (b) they extended the fix itself and have their own patch. I have noticed occasional red hat specific maven jars via mvnrepository, although don't think I saw one for 2.8.9.

I hope to release 2.8.10 quite soon now (have been hoping to batch up more fixes since it's potentially the last 2.8 patch), and 2.9.1 within maybe 2 weeks or so (similarly hoping to batch more fixes, not many yet for 2.9).

[OlivierJaquemet]

2.8.10 was release on 24 aug 2017 : https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.8.10

Shouldn't this issue be closed ? and the 2.8.10 milestone marked as completed (at the specified date) ?

[cowtowncoder]

@OlivierJaquemet yes, thank you.