[jira] [Commented] (TIKA-3019) [9.8] [CVE-2019-17571] [tika-app] [1.23]

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (TIKA-3019) [9.8] [CVE-2019-17571] [tika-app] [1.23]

Sebastian Nagel (Jira)

    [ https://issues.apache.org/jira/browse/TIKA-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17010262#comment-17010262 ]

Kenneth William Krugler commented on TIKA-3019:
-----------------------------------------------

Hi [~tallison] - if we're explicitly using Log4J 1.x in Tika (not for tests) then we would want to switch to Log4J 2 (and the corresponding Slf4J bridge). Otherwise it's up to the Tika user to configure their system to use Log4J 2. Or at least that's my reading of the above.

> [9.8] [CVE-2019-17571] [tika-app] [1.23]
> ----------------------------------------
>
>                 Key: TIKA-3019
>                 URL: https://issues.apache.org/jira/browse/TIKA-3019
>             Project: Tika
>          Issue Type: Bug
>          Components: tika-batch
>    Affects Versions: 1.23
>            Reporter: Aman Mishra
>            Priority: Major
>
> *Description :*
> *Severity :* Sonatype CVSS 3: 9.8CVE CVSS 2.0: 0.0
> *Weakness :* Sonatype CWE: 502
> *Source :* National Vulnerability Database
> *Categories :* Data
> *Description from CVE :* Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.
> *Explanation :* The log4j:log4j package is vulnerable to Remote Code Execution [RCE] due to Deserialization of Untrusted Data. The configureHierarchy and genericHierarchy methods in SocketServer.class do not verify if the file at a given file path contains any untrusted objects prior to deserializing them. A remote attacker can exploit this vulnerability by providing a path to crafted files, which result in arbitrary code execution when deserialized.
> NOTE: Starting with version[s] 2.x, log4j:log4j was relocated to org.apache.logging.log4j:log4j-core. A variation of this vulnerability exists in org.apache.logging.log4j:log4j-core as CVE-2017-5645, in versions up to but excluding 2.8.2.
> *Detection :* The application is vulnerable by using this component.
> *Recommendation :* Starting with version[s] 2.x, log4j:log4j was relocated to org.apache.logging.log4j:log4j-core. A variation of this vulnerability exists in org.apache.logging.log4j:log4j-core as CVE-2017-5645, in versions up to but excluding 2.8.2. Therefore,it is recommended to upgrade to org.apache.logging.log4j:log4j-core version[s] 2.8.2 and above. For log4j:log4j 1.x versions however, a fix does not exist.
> *Root Cause :* tika-app-1.23.jarorg/apache/log4j/net/SocketServer.class : [,]
> *Advisories :* Project: [https://bugzilla.redhat.com/show_bug.cgi?id=1785616]
> *CVSS Details :* Sonatype CVSS 3: 9.8CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H



--
This message was sent by Atlassian Jira
(v8.3.4#803005)