CVE-2023-48795

A flaw was found in the SSH channel integrity. By manipulating sequence numbers during the handshake, an attacker can remove the initial messages on the secure channel without causing a MAC failure. For example, an attacker could disable the ping extension and thus disable the new countermeasure in OpenSSH 9.5 against keystroke timing attacks.

This CVE is classified as moderate because the attack requires an active Man-in-the-Middle (MITM) who can intercept and modify the connection's traffic at the TCP/IP layer.

Although the attack is cryptographically innovative, its security impact is fortunately quite limited. It only allows the deletion of consecutive messages, and deleting most messages at this protocol stage prevents user authentication from proceeding, leading to a stalled connection.

The most significant identified impact is that it enables a MITM to delete the SSH2_MSG_EXT_INFO message sent before authentication begins. This allows the attacker to disable a subset of keystroke timing obfuscation features. However, there is no other observable impact on session secrecy or session integrity.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

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