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

Solution Verified - Updated

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. Please refer to the This content is not included.security bulletin - RHSB-2021-009 for further information on this vulnerability and impacted Red Hat products.

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 This content is not included.log4j-core-2.14.0.redhat-00005.jar in the This content is not included.Red Hat Maven Repository as well it is available on the Customer Support Portal via This content is not included.CVE-2021-44228 Incremental Maven Repository.

Do note that EAP 6.x does provide log4j1, which has a similar but more limited vulnerability that impacts only its JMSAppender per CVE-2021-4104. So EAP 6.x may be vulnerable to CVE-2021-4104 if any JMSAppenders are enabled. So given the lower prevalence in configs with log4j1, this is rated as moderate. Such a JMSAppender would not be enabled by default and not typically used in most customized logging configurations, but if used, any such JMSAppenders may be disabled for immediate mitigation. EAP 7.x's log manager does port in log4j JMSAppender code so is similarly impacted by CVE-2021-4104 with enabled JMSAppenders. But in further reviewing this vulnerability, we have determined this can only be considered a true vulnerability when the attacker has write access to the Log4j configuration to add a JMSAppender to the attacker's JMS Broker. So the attack vector is greatly reduced as it depends on an attacker having write access to compromise the configuration to begin with as noted in CVE-2021-4104.

For EAP 7.4.3, we have issued a This content is not included.one-off patch addressing CVE-2021-4104, CVE-2022-23302, CVE-2022-23305 and CVE-2022-23307. These are also addressed in EAP 7.4.4+. No patch updates are issued for EAP 7.3 or older releases.

Application usage

If 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.17.0 onwards in your application to as possible.
If you can not update the application log4j 2.x libraries immediately, use either of the following mitigations written in This content is not included.security bulletin - RHSB-2021-009:

  • 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, add the following in $JBOSS_HOME/bin/standalone.conf: 
    JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
    • for example, add the following in $JBOSS_HOME/bin/standalone.conf.bat (Windows) : 
    set "JAVA_OPTS=%JAVA_OPTS% -Dlog4j2.formatMsgNoLookups=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 the JndiLookup class from the log4j-core jar in the classpath. For example: 
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

FAQ:

Q1. Is EAP 6/7 affected by CVE-2021-44228?
A1. No. EAP 7 does not have log4j-core libs and nor the vulnerable classes.

Q2. Is EAP 6/7 affected by CVE-2021-4104?
A2. If any JMSAppenders are enabled it can be vulnerable ( JMSAppender is not be enabled by default and not typically used in most customized logging configurations), but if used, any such JMSAppenders should be disabled for an immediate mitigation.

Q3. Is there any action required for EAP 7.x in regards to CVE-2021-44228 ?
A3. No, not if you are only using the log4j API provided by the EAP runtime.

Q4. How to know the application(s) do package the log4j affected?
A4. Search the application internal libraries for log4j core version < 2.15.

Q5. If the application includes its own log4j core version below 2.15, what should we do?
A5. Discuss with the development team to update the application's log4j, ASAP and consider suggested mitigations for this vulnerability.

Q6. We use EAP 6.x is there any action that must be taken?
A6. No action needs to be taken.

Q7. Is there a patch for CVE-2021-44228 since EAP 7 is not affected?
A7. EAP 7 does not use log4j-core 2.x at runtime and does not package log4j-core 2.x jar. There is a patch for EAP 7.4 maven repository: This content is not included.CVE-2021-Incremental Maven Repository, which provides a fixed version (2.15.0) of log4j-core 2.x jar for the EAP 7.4's maven repo. For any question, see Maven patch CVE-2021-Incremental Maven Repository for EAP 7.4

Q8. Does eap-runtime-artifacts Maven BOM need to be updated?
A8. No, log4j-core 2.x is not a part of runtime artifact in EAP and it is not inside of EAP. The log4j version mentioned in the This content is not included.eap-runtime-artifacts BOM is log4j-api which is not where the bug exists.

Q9. The link Security CVE - CVE-2021-44228 shows eap7 as being affected and referencing log4jcore, why?
A9. EAP 6/7 does not include log4j-core in the runtime, but the This content is not included.Red Hat Maven Repository does contain log4j-core and the This content is not included.Red Hat JBoss Enterprise Application Platform Maven Repository Zip . This was made as an overabundance of caution because applications may have inadvertently packaged log4j-core into the application instead of using the provided log4j-api in EAP (which uses jboss-logging and is not affected by the CVE). If this is the case the application should be updated see Application usage above. The fixed log4j-core log4j-core-2.14.0.redhat-00005.jar was published in the Red Hat This content is not included.Maven Repository and also as a This content is not included.Red Hat JBoss Enterprise Application Platform Maven Repository Zip for those using the Red Hat Maven Repository.

Q10. What is RHSA-2021:5140
A10. This is the advisory that fixed the log4j-core jar in the Red Hat Maven Repository, see Q9 above for more details.

Q11: Is Apache log4j 2.17.0 supported in JBoss EAP?
A11: JBoss EAP 6/7 uses JBoss Logging for its logging implementation, the log4j, slf4j, apache commons logging in JBoss EAP are just APIs that proxy to JBoss Logging. User applications can exclude the JBoss EAP logging APIs and package their own log4j, slf4j, apache commons logging, etc in the application and use it for the application logging. If the application packages its own logging framework and excludes the EAP logging APIs, then this is considered application code and is supported by the application developer because it is not shipped in EAP and appears to EAP as just application code and is not integrated with EAP.

Q12: Is there way to test a system to see if it is vulnerable?
A12: There is a detection script available on This content is not included.RHSB-2021-009

Q13: Is appclient affected by the CVE
A13: The $JBOSS_HOME/bin/appclient.sh uses jboss-modules and only has access to the classes in $JBOSS_HOME, so the only way there is an issue is if the application bundles the vulnerable log4j-core or if you create a custom JBoss Module that includes the vulnerable log4j-core. If the application is packaging the vulnerable log4j-core or you have it in a custom module, then those jars should be updated to protect against the CVE.

Q14. Why are the EAP rpms still using eap7-log4j-2.14.0
A14: The eap7-log4j rpm is log4j-api.jar, it is NOT log4j-core where the CVEs exist

Q15. We've updated to EAP 7.4.4+ so why are tennable or other scanners still reporting CVE-2021-4104 concerns with the modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.2.0.Final-redhat-00001.jar file?
A15: This is the original unpatched version of this jar provided by EAP 7.4.0. It does contain code based on log4j 1.2 and contains the log4j JMSAppender with the vulnerable code. But after EAP 7.4.4+, this jar is no longer used by EAP at runtime though it is not removed. A later version provided by your applied cumulative patches and contained within the patch overlay directory is used at runtime instead of this original 7.4.0 log4j-jboss-logmanager-1.2.0.Final-redhat-00001.jar. So any scan against log4j-jboss-logmanager-1.2.0.Final-redhat-00001.jar for CVE-2021-4104 is reported based on nothing more than the presence of this file and is not really relevant to any vulnerability that actually applies to running EAP 7.4.4+ processes, which use a later patched version of log4j-jboss-logmanager. You can observe and confirm the jar your JBoss process is actually using at runtime with a simple lsof command:

lsof -p $JBOSS_PID | grep "log4j-jboss-logmanager"

So you could ignore such a report in that case. Or if you want to avoid any false scan concern against the original 7.4.0 jar, you could remove the original 7.4.0 modules/system/layers/base/org/jboss/log4j/logmanager/main/log4j-jboss-logmanager-1.2.0.Final-redhat-00001.jar file for EAP 7.4.4+ now that it is no longer used.

Related Solutions

Diagnostic Steps

SBR
Product(s)
Components
Category
Tags

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.