Patch for SSH vulnerability CVE-2023-48795 Terrapin attacks

[cepton]

Hi TrevorH,

I have tried editing the sshd_config by setting the safe list of algo's and encryptions, and it looks like it's working fine now.

Thanks again!

Can you explain us what you did ?

[moonwang]

Hi cepton,

Sure. This was the process I've gone through:

1. check the current sshd config allowed cipher method:
sshd -T | grep -i 'MAC'
sshd -T | grep -i 'cipher'

2. backup the sshd_config ()
cp /path/to/sshd_config /path/to/sshd_config.bak

3. update sshd_config:
vi /path/to/sshd_config

4. Add the following to the last line
ciphers xxx,xxx,xxx
MACs xxx,xxx,xxx

only keep the algo's you wanted to allow in a comma separated list.

Be sure to remove the vulnerable algo's:
ciphers: chacha20-poly1305@openssh.com
MACs: anything containing -etm@openssh.com

5. restart sshd service
service sshd restart

You can do the same for the ssh_config.

6. To check if succesful, run a nmap check to the remote server from your local:
(install nmap: https://nmap.org/download.html#linux-rpm)
nmap --script ssh2-enum-algos -sV -p [PORT_NUMBER] [REMOTE_SERVER_IP_ADDRESS]

This should show you the list of algo's with the vulnerables removed.

Hope it helps!

[moonwang]

You could perhaps use EL8 or EL9 SRPMs and rebuild ...

IMHO, an install of EL8 or EL9 based distro is the "least effort" way to get supported ssh (and distro).
Yes, it has its own hurt, but that hurt is inevitable (Soon™).

it looks like the crypto policy scripts are not available in EL7

Red Hat introduced central crypto policies in EL8. One tool offers (crypto bits of) config for multiple programs/services/systems:
• GnuTLS library (GnuTLS, SSL, TLS)
• OpenSSL library (OpenSSL, SSL, TLS)
• NSS library (NSS, SSL, TLS)
• OpenJDK (java-tls, SSL, TLS)
• Libkrb5 (krb5, kerberos)
• BIND (BIND, DNSSec)
• OpenSSH (OpenSSH, SSH)
• Libreswan (libreswan, IKE, IPSec)
• libssh (libssh, SSH)

For example, the sshd config in EL9 does contain:

Code: Select all

# This system is following system-wide crypto policy. The changes to
# crypto properties (Ciphers, MACs, ...) will not have any effect in
# this or following included files. To override some configuration option,
# write it before this block or include it before this file.
# Please, see manual pages for update-crypto-policies(8) and sshd_config(5).
Include /etc/crypto-policies/back-ends/opensshserver.config

As you found, EL7 does not yet have such tool; one has to modify configs "manually".
(The sshd in EL7 does not have the 'Include' keyword either.)

Thanks jlehtone!

I agree that upgrading to el8/9 would be ideal. That's in the plan.

We just wanted to have a hotfix to get this issue off the list first.

Noted for the use of crypto policy in el8/9. very handy!

[jlehtone]

4. Add the following to the last line
ciphers xxx,xxx,xxx
MACs xxx,xxx,xxx

Note: sshd -- at least on EL9 -- does use first occurrence for most options.
For example, if config contains:

Code: Select all

ciphers a,b,c
ciphers b,x

then the effective config is: ciphers a,b,c

Luckily, the default config file does not set "ciphers" or "MACs" in EL7, so appending those option is ok.

[ronon]

I have a CentOS9 with OpenSSH Server 8.7p1 Release 35 and a RedHat 9 with Server 8.7p1 Release 34.

On both OS, there is currently no Terrapin patch for OpenSSH in the official repositories, can that even be correct?

[TrevorH]

That is currently correct. See https://access.redhat.com/security/cve/cve-2023-48795 for more info. Red Hat apparently believe this is not a particularly important vulnerability and have rated it as "Moderate" impact. The list of affected versions lists both RHEL 8 and 9 as affected but there is no code fix released as yet. There is a list of mitigations in that link that can be used to bypass the problem.

[TrevorH]

For CentOS 7 I ran sshd -T | grep -iE "poly|etm" and got back

Code: Select all

ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
macs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

I then removed all mention of poly and etm from both lines yielding

Code: Select all

ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,cast128-cbc,3des-cbc
macs umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

and added those to /etc/ssh/sshd_config and ran systemctl restart sshd then opened a new ssh connection to make sure it still worked. It did. I've also downloaded the Terrapin vulnerability scanner and after this change, it reports the server as NOT VULNERABLE. Prior to this change the scanner reports

The scanned peer is VULNERABLE to Terrapin.

Also, the client side needs changes to make that more secure too and for that, on el7, I added

Code: Select all

        ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
        macs umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

to /etc/ssh/ssh_config under the Host * section.

[cepton]

Hi cepton,
...

It Helped a lot , thanks, i was able to remediate the issue.

[canuck15]

In other words the impact of the issue is too low for Red Hat to allocate resources for fix for el7.

The maintenance support for RHEL 7 ends June 30, 2024 and therefore CentOS has EoL June 30, 2024.
Since there are only six months left, it would be smarter to shift to some other distro now than to hack CentOS 7.

Replacing a server is not always an option. It would have been nice if CE7 was upgradeable like Debian is. All the more reason to go with Debian moving forward.