RHSA-2022:0507HighCVSS 9.8

Red Hat Security Advisory: Red Hat JBoss Data Virtualization 6.4.8.SP2 security update

Published
February 10, 2022
Last Modified
August 4, 2026

🔗 CVE IDs covered (6)

CVE-2019-17571 →CVE-2020-9488 →CVE-2021-4104 →CVE-2022-23302 →CVE-2022-23305 →CVE-2022-23307 →

📋 Description

CVE-2019-17571 — log4j: deserialization of untrusted data in SocketServer CVE-2020-9488 — log4j: improper validation of certificate with host mismatch in SMTP appender CVE-2021-4104 — log4j: Remote code execution in Log4j 1.x when application is configured to use JMSAppender 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 Data Virtualization 6.4.8.SP2

✅ Remediation

Before applying the update, back up your existing installation, including all applications, configuration files, databases and database settings, and so on. The References section of this erratum contains a download link (you must log in to download the update). Workaround: Please note that the Log4j upstream strongly recommends against using the SerializedLayout with the SocketAppenders. Customers may mitigate this issue by removing the SocketServer class outright; or if they must continue to use SocketAppenders, they can modify their SocketAppender configuration from SerializedLayout to use JsonLayout instead. An example of this in log4j-server.properties might look like this: log4j.appender.file.layout=org.apache.log4j.JsonLayout Workaround: Previous versions can set the system property mail.smtp.ssl.checkserveridentity to true to globally enable hostname verification for SMTPS connections. 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: 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 (11)