You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@logging.apache.org by "Ralph Goers (Jira)" <ji...@apache.org> on 2020/03/05 06:07:00 UTC

[jira] [Comment Edited] (LOG4J2-2796) CVEs in the execution path imported by dependencies

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

Ralph Goers edited comment on LOG4J2-2796 at 3/5/20, 6:06 AM:
--------------------------------------------------------------

Yes.  Log4j provides the log4j-slf4j-impl jar built against SLF4J 1.7.25 to provide compatibility for users who use SLF4J 1.7.x even when using EventData and EventDataConverter, even though it has a CVE against it We cannot break backward compatibility without affecting our end users. The fact that SLF4J decided to "fix" the problem by dropping these classes forces us to do this to allow SLF4J users to continue to be able to update Lof4j. slf4j-ext, which is the component where the problem exists is an optional dependency so it does not need to be included by end users Users are also free to use versions newer than SLF4J 1.7.25 with Log4j and Log4j will work just fine, although (of course) the support for EventData and EventDataConverter won't work any more since the SLF4J classes won't be present.

We also provide the log4j-slf4j18-impl jar for users who use SLF4J 1.8.x as it broke backward compatibility with SLF4J implemenations. Users who use SLF4J 1.7.x cannot use this jar.

As such, the SLF4J CVEs have already been handled by Log4j and so this Jira issue is closed as invalid.

 


was (Author: ralph.goers@dslextreme.com):
Yes.  Log4j provides the log4j-slf4j-impl jar built against SLF4J 1.7.25 to provide compatibility for users who use SLF4J 1.7.x even when using EventData and EventDataConverter, even though it has a CVE against it We cannot break backward compatibility without affecting our end users. The fact that SLF4J decided to "fix" the problem by dropping these classes forces us to do this to allow SLF4J users to continue to be able to update Lof4j. slf4j-ext, which is the component where the problem exists is an optional dependency so it does not need to be included by end users Users are also free to use versions newer than SLF4J 1.7.25 with Log4j and Log4j will work just fine.

We also provide the log4j-slf4j18-impl jar for users who use SLF4J 1.8.x as it broke backward compatibility with SLF4J implemenations. Users who use SLF4J 1.7.x cannot use this jar.

As such, the SLF4J CVEs have already been handled by Log4j and so this Jira issue is closed as invalid.

 

> CVEs in the execution path imported by dependencies
> ---------------------------------------------------
>
>                 Key: LOG4J2-2796
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2796
>             Project: Log4j 2
>          Issue Type: Dependency upgrade
>            Reporter: XuCongying
>            Priority: Major
>         Attachments: apache-logging-log4j2_CVE-report.md
>
>
> Hello, Your project are using some dependencies with CVEs. I found that the buggy methods of the CVEs are in the program execution path of your project. To prevent potential security risks it may cause, I suggest to update the library dependency. Please look into the details below.
>  * *Vulnerable Dependency:* org.slf4j : slf4j-ext : 1.7.25
>  * *Call Chain to Buggy Methods:*
>  ** *Some files in your project call the library method org.slf4j.ext.EventData.getMessage(), which can reach the buggy method of [CVE-2018-8088|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088].*
>  *** Files in your project:  log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/EventDataConverter.java
>  *** One of the possible call chain:
> org.slf4j.ext.EventData.getMessage() [buggy method]
>  ** *Some files in your project call the library method org.slf4j.ext.EventData.getEventMap(), which can reach the buggy method of [CVE-2018-8088|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088].*
>  *** Files in your project:  log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/EventDataConverter.java
>  *** One of the possible call chain:
> org.slf4j.ext.EventData.getEventMap() [buggy method]
>  ** *Some files in your project call the library method org.slf4j.ext.EventData.getEventType(), which can reach the buggy method of [CVE-2018-8088|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088].*
>  *** Files in your project:  log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/EventDataConverter.java
>  *** One of the possible call chain:
> org.slf4j.ext.EventData.getEventType() [buggy method]
>  ** *Some files in your project call the library method org.slf4j.ext.EventData.getEventId(), which can reach the buggy method of [CVE-2018-8088|https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088].*
>  *** Files in your project:  log4j-slf4j-impl/src/main/java/org/apache/logging/slf4j/EventDataConverter.java
>  *** One of the possible call chain:
> org.slf4j.ext.EventData.getEventId() [buggy method]
>  ** *Update suggestion:* version 1.8.0-beta2 1.8.0-beta2 is a safe version without CVEs. From 1.7.25 to 1.8.0-beta2, the APIs used in your project have not changed.



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