Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a component with Known Vulnerability Jackson Deserialize RCE (CVE-2017-7525) #463

Closed
ajinabraham opened this issue Feb 20, 2018 · 4 comments

Comments

@ajinabraham
Copy link

As per the file: https://github.com/msgpack/msgpack-java/blob/develop/build.sbt#L118
It looks like msgpack-java is using jackson-databind 2.7.1 which has a known security vulnerability CVE-2017-7525.
Ref: FasterXML/jackson-databind#1599
Exploit: https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/
The issue is fixed in 2.8.10. Please update the library.

@komamitsu
Copy link
Member

@ajinabraham Thanks for letting us know that.

jackson-databind 2.8.10 affects the serialization performance of jackson-dataformat-msgpack. So we chose 2.7.9.1 instead which addresses the security vulnerability as well.

@ajinabraham
Copy link
Author

ajinabraham commented Feb 20, 2018

@komamitsu Are you sure this is completely patched in 2.7.9.1.

The author says the fix is included in 2.7.9.3 and 2.7.9.2 but not in 2.7.9.1
FasterXML/jackson-databind#1855 (comment)

I couldn't find the complete fix in 2.7.9.1 as well. You can verify this by looking for https://github.com/FasterXML/jackson-databind/blob/2.9/src/main/java/com/fasterxml/jackson/databind/jsontype/impl/SubTypeValidator.java in the corresponding branch or release.

I also saw few bypass gadgets addressed here and fixed only in 2.8 and 2.9 branches.
FasterXML/jackson-databind#1899 (comment)

@komamitsu
Copy link
Member

Hmm.. I saw this comment FasterXML/jackson-databind#1599 (comment).

But FasterXML/jackson-databind#1855 and FasterXML/jackson-databind#1899 were created after that. It's like whack-a-mole...

Okay. I'll look into it again tomorrow.

@komamitsu komamitsu reopened this Feb 20, 2018
@ajinabraham
Copy link
Author

I agree, blacklist is not the right way. But it offers some level of defence. Again it's a security vs performance decision. Your call. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants