Is JBoss EAP 6.x/7.x impacted by log4j vulnerabilities CVE-2021-44228 or CVE-2021-4104?

Environment

  • Red Hat JBoss Enterprise Application Platform (EAP)
    • 6.x
    • 7.x
  • Log4j
    • 2.0.0 < 2.15

Issue

Resolution

No version of JBoss EAP 6.x/7.x is vulnerable to CVE-2021-44228 currently thanks to the usage of JBoss Logging framework instead of Log4J.

While JBoss EAP 7 is marked as Affected in CVE Page, it is not actually vulnerable (meaning: Not exploitable). By Industry Standard, Affected means “present in the distribution, irrespective of the exploitability”. Vulnerable means that it is actually exploitable and for CVE-2021-44228, it is only vulnerable in respect to the Maven Repository of EAP if an application was packaging the affected jar from this (as the affected jar is not distributed in the EAP Zip, Container, nor RPM, thus the EAP runtimes are not affected and not vulnerable to CVE-2021-44228).

The Red Hat Maven repository does contain a version of log4j-core 2.x which is affected, this has been patched via log4j-core-2.14.0.redhat-00005.jar in the Red Hat Maven Repository as well it is available on the Customer Support Portal via CVE-2021-44228 Incremental Maven Repository.

f the application(s) bundle and use log4j versions between 2.0 and 2.14.1 (on or off JBoss EAP), it has a possibility to be affected by this vulnerability. Note that attacks depend on application behavior that sends remote user input (such as via an HTTP request) to log4j logging calls. So, we highly recommend upgrading your used log4j 2.x libraries to 2.16.0 onwards in your application to as possible.

  • Set the system property log4j2.formatMsgNoLookups to true, or set the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true(Note: this mitigation works only if the log4j version is 2.10.0 and later.)
    • for example in $JBOSS_HOME/bin/standalone.conf : 
  ...
  JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
  • for example in $JBOSS_HOME/bin/standalone.conf.bat (Windows) : 
....
set "JAVA_OPTS=%JAVA_OPTS% -Djboss.modules.lockless=true"
  • Modify logging format (PatternLayout patterns) to specify the message converter as %m{nolookups} instead of just %m. (Note: this mitigation works only if the log4j version is 2.7 and later.)

Remove JNDI lookup class using below command

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *