RHSA-2024:4597HighCVSS 8.8

Red Hat Security Advisory: Red Hat Product OCP Tools 4.15 OpenShift Jenkins security update

Published
July 17, 2024
Last Modified
August 25, 2026

🔗 CVE IDs covered (9)

CVE-2024-28149 →CVE-2024-34145 →CVE-2023-48795 →CVE-2024-21626 →CVE-2024-23899 →CVE-2024-24786 →CVE-2024-34144 →CVE-2024-22201 →CVE-2024-23900 →

📋 Description

CVE-2023-48795 — ssh: Prefix truncation attack on Binary Packet Protocol (BPP) CVE-2024-21626 — runc: file descriptor leak CVE-2024-22201 — jetty: stop accepting new connections from valid clients CVE-2024-23899 — jenkins-2-plugins: git-server plugin arbitrary file read vulnerability CVE-2024-23900 — jenkins-2-plugins: matrix-project plugin path traversal vulnerability CVE-2024-24786 — golang-protobuf: encoding/protojson, internal/encoding/json: infinite loop in protojson.Unmarshal when unmarshaling certain forms of invalid JSON CVE-2024-28149 — jenkins-2-plugins: Improper input sanitization in HTML Publisher Plugin CVE-2024-34144 — jenkins-plugin/script-security: sandbox bypass via crafted constructor bodies CVE-2024-34145 — jenkins-plugin/script-security: sandbox bypass via sandbox-defined classes

🎯 Affected products5

  • OpenShift Developer Tools and Services for OCP 4.15
  • jenkins-0:2.440.3.1718879390-3.el8.noarch as a component of OpenShift Developer Tools and Services for OCP 4.15
  • jenkins-0:2.440.3.1718879390-3.el8.src as a component of OpenShift Developer Tools and Services for OCP 4.15
  • jenkins-2-plugins-0:4.15.1718879538-1.el8.noarch as a component of OpenShift Developer Tools and Services for OCP 4.15
  • jenkins-2-plugins-0:4.15.1718879538-1.el8.src as a component of OpenShift Developer Tools and Services for OCP 4.15

✅ Remediation

For details on how to apply this update, which includes the changes described in this advisory, refer to: https://access.redhat.com/articles/11258 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 Workaround: Red Hat Enterprise Linux (RHEL) and OpenShift ships with SELinux in targeted enforcing mode, which prevents the container processes from accessing host content and mitigates this attack. Dockerfiles can be inspected on the 'RUN' and 'WORKDIR' directives to ensure that there are no escapes or malicious paths, which are an indication of compromise. Limiting access and only using trusted container images can help prevent unauthorized access and malicious attacks. Workaround: Mitigation for this issue is either not available or the currently available options don't meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability. Workaround: Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.

🔗 References (12)