[ https://issues.apache.org/jira/browse/TIKA-2717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16757341#comment-16757341 ]
Hudson commented on TIKA-2717: ------------------------------ SUCCESS: Integrated in Jenkins build tika-branch-1x #160 (See [https://builds.apache.org/job/tika-branch-1x/160/]) TIKA-2717 -- upgrade jackson (tallison: [https://github.com/apache/tika/commit/c566e652cd30d8bc28f484130252d17e3ee9eb5c]) * (edit) tika-parent/pom.xml > Sonatype Nexus auditor is reporting that Jackson databind version used by > Apache Tika is vulnerable > --------------------------------------------------------------------------------------------------- > > Key: TIKA-2717 > URL: https://issues.apache.org/jira/browse/TIKA-2717 > Project: Tika > Issue Type: Bug > Components: core > Affects Versions: 1.18 > Reporter: Abhijit Rajwade > Priority: Critical > > Sonatype Nexus auditor is reporting that Jackson databind version used by > Apache Tika is vulnerable. Recommendation is not to use global default typing > with Jackson, > Refer following for details. > > Source Sonatype Data Research > > Severity Sonatype CVSS 3.0: 8.5 > > Weakness Sonatype CWE: [502|https://cwe.mitre.org/data/definitions/502.html] > > Explanation > {{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 that will result in > RCE if the application attempts to deserialize it. > Note: This vulnerability exists due to the incomplete fix for CVE-2017-7525, > CVE-2017-15095, CVE-2017-17485, CVE-2018-5968, and CVE-2018-7489. Evidence of > this can be found at [https://pivotal.io/security/cve-2017-4995]: > {quote}Jackson provides a blacklisting approach to protecting against this > type of attack, but Spring Security should be proactive against blocking > unknown “deserialization gadgets” when Spring Security enables default typing. > {quote} > > Detection > The application is vulnerable by using this component, when default typing is > enabled and passing in untrusted data to be deserialization. > Note: Spring Security has provided their own fix for this vulnerability > ([CVE-2017-4995|https://pivotal.io/security/cve-2017-4995]). If this > component is being used as part of Spring Security, then you are not > vulnerable if you are running Spring Security 4.2.3.RELEASE or greater for > 4.x or Spring Security 5.0.0.M2 or greater for 5.x. > > Recommendation > There is no non vulnerable version of this component. We recommend > investigating alternative components or a potential mitigating control. > Workaround: Do not use the default typing. Instead you will need to implement > your own. > {quote}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. > {quote} > > Reference: > [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/spring-projects/spring-security/commit/947d11f433b78294942cb5ea56e8aa5c3a0ca439] > or [this Stack Overflow > article|https://stackoverflow.com/questions/12353774/how-to-customize-jackson-type-information-mechanism]. > > Categories > Data > Root Cause > tika-app-1.18.jar *<=* SubTypeValidator.class : [2.9.5, ) > Advisories > Attack: > [https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cv...|https://adamcaudill.com/2017/10/04/exploiting-jackson-rce-cve-2017-7525/] > Evidence: [https://pivotal.io/security/cve-2017-4995] -- This message was sent by Atlassian JIRA (v7.6.3#76005)