Do we have plan to release an update on sshd to address the Terrapin attack soon? Our Security Team is on our back to address the vulnerability. Thank you. James
You might want to watch the bugzilla entry. We are lagging quite a bit in terms of the openssh version in Fedora, and I don’t see any backports since September.
On the other hand, terrapin does not appear to be overly critical, and you can always exclude those two algorithms in config until updates are here. Some news sound more scary than necessary (as far as I can tell).
1 Like
Thank you Michael. Could you show me how to exclude the algorithms in config. I put follow line in shd_config
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,aes128-gcm@openssh.com
Restarted sshd. Scan still shows
Remote Banner: SSH-2.0-OpenSSH_9.3
ChaCha20-Poly1305 support: true
CBC-EtM support: false
Strict key exchange support: false
The scanned peer is VULNERABLE to Terrapin.
Thanks.
Which scanner are you using? Note that some scanners simply check the banner (SSH-2.0-OpenSSH_9.3) and infer everything else from that.
From the bug linked from the bug that I linked to (…), you can use a crypto sub-policy. That is, put
cipher@SSH = -CHACHA20-POLY1305
ssh_etm = 0
into (e.g.) /etc/crypto-policies/policies/modules/CVE-2023-48795.pmod and apply with
update-crypto-policies --set $(update-crypto-policies --show):CVE-2023-48795
and restart the server service. (no need to change sshd_config)
This amends the current policy with that subpolicy.
As per the mentioned bug, you can verify the changed config in the resulting files in /etc/crypto-policies/back-ends/ (openssh and opensshserver).
I am using the scanner from Terrapin Attack. After applied your suggestions, it now shows “Not vulnerable”.
I will populate it to our other servers.
Thank you!
James