tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kenneth William Krugler (Jira)" <j...@apache.org>
Subject [jira] [Commented] (TIKA-3019) [9.8] [CVE-2019-17571] [tika-app] [1.23]
Date Wed, 08 Jan 2020 20:00:18 GMT

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

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

For option (a), I think they'd want to:

* Remove the log4j 2 file(s) (typically just log4j-core-<version>.jar)
* Remove the `log4j-slf4j-impl-<version>.jar` file.
* Add the `slf4j-log4j12-<version>.jar`
* Add the appropriate log4j 1.x jar(s)

I'd run into issues with having both log4j 1.x and 2.x on the classpath, though that might
have been due to weird dependencies in Elasticsearch.

> [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)

Mime
View raw message