Latest log4j CVE's
169 views
Skip to first unread message
James Perkins
Jan 20, 2022, 4:54:10 PM1/20/22
to WildFly
Hello All,
As you may be aware there are 3 new log4j CVE's.
Both CVE-2022-2302 and CVE-2022-2307 are CVE's in standalone applications. JMSSink and Chainsaw respectively. It is not necessarily straight forward to launch these in WildFly due to the "forked" version of log4j that WildFly uses.
CVE-2022-23305 is slightly different as it's vector is through the JDBCAppender. This appender cannot be configured out of the box in WildFly and therefore is likely not an issue. If you have somehow configured WildFly to use this appender you may want to remove it. Your other option is to ensure that no log messages can be originated from user input.
Overall it's my opinion that for WildFly none of these are a strong threat. For this reason a there will not be a fix in WildFly 26.0.1.Final. However, we will address these in a future release of WildFly. It's currently undetermined if this means removing log4j 1.x support, patching our "forked" version of log4j or both. You can WFCORE-5781 for the removal decision.
If you've got concerns about these types being available at all you can execute the following to remove the offending classes:
zip -q -d $JBOSS_HOME/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-*.jar org/apache/log4j/net/JMSAppender.class org/apache/log4j/net/JMSSink.class org/apache/log4j/jdbc/JDBCAppender.class /org/apache/log4j/chainsaw/*
--
James R. Perkins
As you may be aware there are 3 new log4j CVE's.
- https://access.redhat.com/security/cve/CVE-2022-23302
- https://access.redhat.com/security/cve/CVE-2022-23305
- https://access.redhat.com/security/cve/CVE-2022-23307
Both CVE-2022-2302 and CVE-2022-2307 are CVE's in standalone applications. JMSSink and Chainsaw respectively. It is not necessarily straight forward to launch these in WildFly due to the "forked" version of log4j that WildFly uses.
CVE-2022-23305 is slightly different as it's vector is through the JDBCAppender. This appender cannot be configured out of the box in WildFly and therefore is likely not an issue. If you have somehow configured WildFly to use this appender you may want to remove it. Your other option is to ensure that no log messages can be originated from user input.
Overall it's my opinion that for WildFly none of these are a strong threat. For this reason a there will not be a fix in WildFly 26.0.1.Final. However, we will address these in a future release of WildFly. It's currently undetermined if this means removing log4j 1.x support, patching our "forked" version of log4j or both. You can WFCORE-5781 for the removal decision.
If you've got concerns about these types being available at all you can execute the following to remove the offending classes:
zip -q -d $JBOSS_HOME/modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-*.jar org/apache/log4j/net/JMSAppender.class org/apache/log4j/net/JMSSink.class org/apache/log4j/jdbc/JDBCAppender.class /org/apache/log4j/chainsaw/*
--
James R. Perkins
Reply all
Reply to author
Forward
0 new messages