RHSA-2024:0954HighCVSS 8.8

Red Hat Security Advisory: Red Hat OpenShift for Windows Containers 10.15.0 security update

Published
February 27, 2024
Last Modified
September 7, 2026

🔗 CVE IDs covered (3)

CVE-2023-5528 →CVE-2023-39325 →CVE-2023-48795 →

📋 Description

CVE-2023-5528 — kubernetes: Insufficient input sanitization in in-tree storage plugin leads to privilege escalation on Windows nodes CVE-2023-39325 — golang: net/http, x/net/http2: rapid stream resets can cause excessive work (CVE-2023-44487) CVE-2023-48795 — ssh: Prefix truncation attack on Binary Packet Protocol (BPP)

🎯 Affected products3

  • Red Hat OpenShift Container Platform 4.15
  • openshift4-wincw/windows-machine-config-operator-bundle@sha256:200fb2eec697aed66f3d68f6bd6f95063fb772cd9b5310e86f49b7c213294e77_amd64 as a component of Red Hat OpenShift Container Platform 4.15
  • openshift4-wincw/windows-machine-config-rhel9-operator@sha256:f7eb46d948e0e53be77cd35543c75d46bbf7f9010b5a2b7ed422830500daf0a5_amd64 as a component of Red Hat OpenShift Container Platform 4.15

✅ Remediation

For Windows Machine Config Operator upgrades, see the following documentation: https://docs.openshift.com/container-platform/latest/windows_containers/windows-node-upgrades.html Workaround: The default stream concurrency limit in golang is 250 streams (requests) per HTTP/2 connection. This value may be adjusted in the golang.org/x/net/http2 package using the Server.MaxConcurrentStreams setting and the ConfigureServer function which are available in golang.org/x/net/http2. Workaround: Update to the last version and check that client and server provide kex pseudo-algorithms indicating usage of the updated version of the protocol which is protected from the attack. If "[email protected]" is provided by clients and "[email protected]" is in the server's reply, no other steps are necessary. Disabling ciphers if necessary: If "[email protected]" is not provided by clients or "[email protected]" is absent in the server's reply, you can disable the following ciphers and HMACs as a workaround on RHEL-8 and RHEL-9: 1. [email protected] 2. [email protected] 3. [email protected] 4. [email protected] 5. [email protected] To do that through crypto-policies, one can apply a subpolicy with the following content: ``` cipher@SSH = -CHACHA20-POLY1305 ssh_etm = 0 ``` e.g., by putting these lines into `/etc/crypto-policies/policies/modules/CVE-2023-48795.pmod`, applying the resulting subpolicy with `update-crypto-policies --set $(update-crypto-policies --show):CVE-2023-48795` and restarting openssh server. One can verify that the changes are in effect by ensuring the ciphers listed above are missing from both `/etc/crypto-policies/back-ends/openssh.config` and `/etc/crypto-policies/back-ends/opensshserver.config`. For more details on using crypto-policies, please refer to https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening Note that this procedure does limit the interoperability of the host and is only suggested as a temporary mitigation until the issue is fully resolved with an update. For RHEL-7: We can recommend to use strict MACs and Ciphers on RHEL7 in both files /etc/ssh/ssh_config and /etc/ssh/sshd_config. Below strict set of Ciphers and MACs can be used as mitigation for RHEL 7. ``` Ciphers aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected] MACs [email protected],[email protected],hmac-sha2-256,hmac-sha2-512 ``` - For Openshift Container Platform 4: Please refer the KCS[1] document for verifying the fix in RHCOS. [1] https://access.redhat.com/solutions/7071748 ~~~ NOTE: The crypto-policies workaround requires RHEL 8.5 or newer. Customers (for older RHEL 8 releases) who cannot immediately update crypto-policies packages may manually configuring Ciphers and MACs directly in /etc/ssh/sshd_config and ssh_config (as used for "RHEL-7") method documented https://access.redhat.com/solutions/7066001 ~~~~

🔗 References (28)