RHSA-2022:1299LowCVSS 8.8

Red Hat Security Advisory: Red Hat JBoss Enterprise Application Platform 7.4.4 security update

Published
April 11, 2022
Last Modified
August 4, 2026

🔗 CVE IDs covered (7)

CVE-2022-23305 →CVE-2022-23307 →CVE-2021-4104 →CVE-2021-44832 →CVE-2021-45046 →CVE-2021-45105 →CVE-2022-23302 →

📋 Description

CVE-2021-4104 — log4j: Remote code execution in Log4j 1.x when application is configured to use JMSAppender CVE-2021-44832 — log4j-core: remote code execution via JDBC Appender CVE-2021-45046 — log4j-core: DoS in log4j 2.x with thread context message pattern and context lookup pattern (incomplete fix for CVE-2021-44228) CVE-2021-45105 — log4j-core: DoS in log4j 2.x with Thread Context Map (MDC) input data contains a recursive lookup and context lookup pattern CVE-2022-23302 — log4j: Remote code execution in Log4j 1.x when application is configured to use JMSSink CVE-2022-23305 — log4j: SQL injection in Log4j 1.x when application is configured to use JDBCAppender CVE-2022-23307 — log4j: Unsafe deserialization flaw in Chainsaw log viewer

🎯 Affected products1

  • Red Hat JBoss Enterprise Application Platform 7

✅ Remediation

Before applying this update, back up your existing Red Hat JBoss Enterprise Application Platform installation and deployed applications. The References section of this erratum contains a download link (you must log in to download the update). Workaround: These are the possible mitigations for this flaw for releases version 1.x: - Comment out or remove JMSAppender in the Log4j configuration if it is used - Remove the JMSAppender class from the classpath. For example: ``` zip -q -d log4j-*.jar org/apache/log4j/net/JMSAppender.class ``` - Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker. Workaround: As per upstream: - In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java. - Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability. Workaround: For Log4j versions up to and including 2.15.0, this issue can be mitigated by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Workaround: For Log4j 2 versions up to and including 2.16.0, this flaw can be mitigated by: - In PatternLayout in the Log4j logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC) like %X{loginId}. - Otherwise, in the Log4j logging configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input. Workaround: These are the possible mitigations for this flaw for releases version 1.x: - Comment out or remove JMSSink in the Log4j configuration if it is used - Remove the JMSSink class from the server's jar files. For example: ``` zip -q -d log4j-*.jar org/apache/log4j/net/JMSSink.class ``` - Restrict access for the OS user on the platform running the application to prevent modifying the Log4j configuration by the attacker. Workaround: These are the possible mitigations for this flaw for releases version 1.x: - Comment out or remove JDBCAppender in the Log4j configuration if it is used - Remove the JDBCAppender class from the server's jar files. For example: ``` zip -q -d log4j-*.jar org/apache/log4j/jdbc/JDBCAppender.class ``` Workaround: These are the mitigations available for this flaw for log4j 1.x: - Avoid using Chainsaw to view logs, and instead use some other utility, especially if there is a log view available within the product itself. - Remove the Chainsaw classes from the log4j jar files. For example: ``` zip -q -d log4j-*.jar org/apache/log4j/chainsaw/* ``` (log4j jars may be nested in zip archives within product)

🔗 References (38)