Security Vulnerability: CVE-2023-48795 SSH prefix truncation attack (aka Terrapin Attack)

For a comprehensive list of affected products, please review the SUSE CVE announcement.

Security researchers from the Ruhr University Bochum have published a new attack on the SSH v2 protocol, which allows active person-in-the-middle attackers to impact SSH connections by removing initial encrypted SSH packets,
which could lead to protocol security downgrades or similar problems.

Changing SSH packages or injecting new encrypted SSH packages is not possible with this attack.

Software on all SUSE Linux Enterprise versions are affected.

The problem is inherent to the existing SSH v2 protocol, so new protocol addition(s) and enforcement of them are needed to avoid the problem.

The protocol vulnerability needs to be exploited in tandem with specific SSH ciphers.

The chacha20-poly1305 SSH cipher is the one that was shown to be exploitable most easily, also other ciphers using Encrypt-Then-MAC Message Authentication Codes (MACs) might be exploitable under certain conditions.

Note that the ciphers themselves are not problematic. Only in combination with the SSH v2 protocol weakness they could lead to exploitable scenarios.

Following SSH v2 implementations are shipped by SUSE, and their exploitability status:

- openssh: is affected in all shipping versions up to 9.5p1, all SLES versions affected.

- putty: is affected (shipped via SUSE PackageHub 15)

- libssh.org (aka libssh): supports chacha20-poly1305 since 0.8.0:
  SLES 12 SP5, SLES 15 SP1 and newer are affected.

- libssh2.org (aka libssh2_org): does not implement chacha20-poly1305 cipher in the newest release 1.11.0. ETM MACs
  were only implemented in 1.11.0, so version before 1.11.0 are not affected.

  SLES 12 SP5 and SLES 15 have version 1.11.0 and are affected by this problem.

- jsch (Java SSH): chacha20-poly1305 was added with version 0.1.66, ETM MACs in 0.1.58. Versions from 0.1.58 to
  current 0.2.9 are considered affected.

  SUSE currently does not ship affected versions of jsch.

- proftpd: Its mod_sftp module is affected (shipped via SUSE PackageHub 15), it supports ETM MACs, but no
  chacha20-poly1305.

  The module is however not default enabled.

- golang.org/x/crypto/ssh: The Golang SSH module is also affected.
  The SSH module is used/included by a long list of software written in GO.

The solution is to install respective updates on server and client machines.

openssh updates were provided on December 18th, other SSH software will get updated after backporting upstream security fixes.

Please note that both SSH clients and servers must be adjusted for the protocol adjustments to be effective.

Mitigations like removal of ciphers can be done on either side to be effective.

Since this might need some time to roll out and not all clients are under administrative control, configuration adjustments like removal of ciphers should be done to avoid the use of impacted ciphers (see the Additional Information section below).

While the issue affects both client and server parts, focusing on mitigating the server side services should have priority.

SUSE is working on publishing fixed packages for this issue and providing mitigation suggestions.
Please revisit this page, as we will update this article as soon new information become available.

Security Alert

This describes workarounds for openssh.

Primary workaround is to temporary disable the chacha20-poly1305@openssh.com cipher.

* For the openssh server side: In the config file /etc/ssh/sshd_config :

  - If there is a Ciphers line, add -chacha20-poly1305@openssh.com to the end
  - If not, add a new Ciphers line
    Ciphers -chacha20-poly1305@openssh.com
    which will remove the chacha20-poly1305 cipher from the default offered ciphers.

* For the openssh client side:

  Use the /etc/ssh/ssh_config file with same approach described above.

Also "encrypt then mac" MACs could be temporary disabled by using:

- MACs -*etm*
 

*  Note for SLES 12 SP5 (and older)

The "-" to remove the cipher was not implemented for this release. Instead, the cipher entry must include all ciphers that are to be enabled in a comma separated list. The following steps can be done to determine what entry should be used:

1.  # sshd -T | grep cipher
This will show the supported ciphers on the server, which will include the trouble-maker.  It would look similar to this:

ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

2.  # vi /etc/ssh/sshd_config
By default there is no ciphers entry, but if it has been added for some reason, just remove the troubled cipher.  Otherwise, go to the section that says "Ciphers and keying" and add a line to tell sshd what ciphers to include.  Copy the list of ciphers from step 1 and remove chacha20-poly1305@openssh.com.  The entry would look similar to this:

ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

3.  # systemctl restart sshd
To verify the cipher is no longer supported, check the list again with the command from step 1.

Please bear in mind these changes only address the SSH daemon side, to strengthen the client side as well, please use

ssh -Q cipher
ssh -Q mac

to identify the supported ciphers/macs and list only those that should be allowed in /etc/ssh/ssh_config in the format like:

Ciphers 3des-cbc,blowfish-cbc,cast128-cbc,arcfour,arcfour128,arcfour256,aes128-cbc,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr

MACs hmac-sha1,hmac-sha1-96,hmac-sha2-256,hmac-sha2-512,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com,umac-64@openssh.com,umac-128@openssh.com

References:
https://www.suse.com/security/cve/CVE-2023-48795/
https://terrapin-attack.com/