RHSA-2022:0444MediumCVSS 8.8

Red Hat Security Advisory: Red Hat Single Sign-On 7.4.10 on OpenJDK for OpenShift image security update

Published
February 7, 2022
Last Modified
September 22, 2026

🔗 CVE IDs covered (4)

CVE-2021-4104 →CVE-2022-23302 →CVE-2022-23305 →CVE-2022-23307 →

📋 Description

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 products2

  • Middleware Containers for OpenShift
  • rh-sso-7/sso74-openshift-rhel8@sha256:7f4c56719e377215a4f2d2526c3974def6e9a02093fd6a8cf3473bcd500e620b_amd64 as a component of Middleware Containers for OpenShift

✅ Remediation

To update to the latest Red Hat Single Sign-On 7.4.10 for OpenShift image, Follow these steps to pull in the content: 1. On your master hosts, ensure you are logged into the CLI as a cluster administrator or user with project administrator access to the global "openshift" project. For example: $ oc login -u system:admin 2. Update the core set of Red Hat Single Sign-On resources for OpenShift in the "openshift" project by running the following commands: $ for resource in sso74-image-stream.json \ sso74-https.json \ sso74-mysql.json \ sso74-mysql-persistent.json \ sso74-postgresql.json \ sso74-postgresql-persistent.json \ sso74-x509-https.json \ sso74-x509-mysql-persistent.json \ sso74-x509-postgresql-persistent.json do oc replace -n openshift --force -f \ https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/v7.4.10.GA/templates/${resource} done 3. Install the Red Hat Single Sign-On 7.4.10 for OpenShift streams in the "openshift" project by running the following commands: $ oc -n openshift import-image redhat-sso74-openshift:1.0 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 (8)