It’s been a busy month here at Sonatype as the tide of vulnerable components continues to rise. Our Data Research team has been investigating a large volume of components and working hard to keep our customers well ahead of the open source software threat.
One of the many ways we help our customers is by examining customer scan results and answering questions about discrepancies. This month’s Nexus Intelligence Insight highlights a question we’ve gotten repeatedly about jackson-databind and block polymorphic deserialization.
Specifically, why we:
- List the component as vulnerable
- Why we don’t list every CVE that covers a vulnerable vector in our scans
First, a little context. In 2013, a developer discovered that DefaultTyping, which is enabled by default, for this component opened up an exploit vector point. He reported it to the project as a potential vulnerability. A member of our Data Research team flagged it for further investigation. After careful analysis, we determined that the proper developer hygiene assumed with the use of this component was complicated enough to make using it with DefaultTyping set to enabled, risky. We don’t believe the project is “wrong” about whether or not the component was or is vulnerable as it works as designed (deserializes code). However, without a fairly significant amount of diligence on behalf of the developer, using the component may open up multiple exploit opportunities.
Name of Vuln/Sonatype ID: SONATYPE-2017-0312
Type of Vulnerability: Remote Code Execution
Components Affected: All components as the versions are updated. Developers using Spring Security: 4.2.3.RELEASE+ or Spring Security: 5.0.0.M2 aren’t exposed to this vulnerability
Vulnerability Description:
`jackson-databind` is vulnerable to Remote Code Execution (RCE). The `createBeanDeserializer()` function in the `BeanDeserializerFactory` class allows untrusted Java objects to be deserialized. A remote attacker can exploit this by uploading a malicious serialized object (typically a gadget) that will result in RCE if the application attempts to deserialize it.
This vulnerability exists due to the inability to fix CVE-2017-7525, CVE-2017-15095, CVE-2017-17485, CVE-2018-5968, CVE-2018-7489, CVE-2018-11307, CVE-2018-12022, CVE-2018-12023, CVE-2018-14718, CVE-2018-14719, CVE-2018-14720, and CVE-2018-14721.
Attack Mechanics:
An application is vulnerable using this component when DefaultTyping is enabled and passing in untrusted data through arbitrary objects to be deserialized. In the example below, the bad actor creates the malicious payload to be deserialized.
FasterXML has implemented a black-list approach to remediate this potential exploit. As those vectors are identified, the blacklist builds:
Sonatype's View:
Sonatype’s position on jackson-databind is that since there is no true fix for this potential vulnerability given the nature of the component and strict developer hygiene is required to restrict deserialization of malicious code, we’ve declared this component vulnerable.
In the interest of “noise” reduction, if a customer is running one of the latest versions of jackson-databind that has all the fixes, for all associated CVEs, Sonatype will show SONATYPE-2017-0312 in the scan. If customers are running a version that is missing any of the CVE patches, we will only show the CVE that is most appropriate for the version in use (i.e. the CVE for the first missing patch). In the Explanation of the CVE that we do show, Sonatype will list all the other prior, relevant CVEs, so all are accounted for, but visually consolidated. Our goal in presenting the vulnerability this way is to eliminate displaying a dozen different individual CVEs/vulnerabilities for what is really the same vulnerability.
For those readers who are customers, Sonatype didn’t miss jackson-databind CVEs in your scan, we’ve simply consolidated them to keep things simple and clean. There are many CVEs and versions associated with this component and the list grows regularly.
Remediation:
We recommend investigating alternative components or a mitigating control. Learn more about mitigation here.
Do not enable DefaultTyping. Instead implement explicitly mapped classes.
It is also possible to customize global defaulting, using ObjectMapper.setDefaultTyping(…) – you just have to implement your own TypeResolverBuilder (which is not very difficult); and by doing so, can actually configure all aspects of type information. Builder itself is just a short-cut for building actual handlers.
Learn more about that here:
https://github.com/FasterXML/jackson-docs/wiki/JacksonPolymorphicDeserialization
Examples of implementing your own typing can be found by looking at Spring Security's fix. https://github.com/springprojects/springsecurity/commit/947d11f433b78294942cb5ea56e8aa5c3a0ca439
or
https://stackoverflow.com/questions/12353774/how-to-customize-jackson-type-information-mechanism
DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of SONATYPE-2017-0312 within days of the discovery. Their development teams automatically received specific instructions on how to remediate the risk. In the specific case of jackson-databind, our Data Research team is continuously monitoring for new vectors, updating and consolidating CVEs and the corresponding version numbers.
If you're not a Sonatype customer and want to find out if you're using this vulnerable version of jackson-databind in a specific application, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.
If you are a Sonatype customer and have additional questions about this component, its presence in a scan or a policy violation, please contact your Customer Success representative.
Interested in learning about other vulnerabilities impacting the open source ecosystem? Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one.
