Has there been a patch issued, or update for version 7, that mitigated the terrapin MitM attack? It’s been almost 90 days since we discovered the vulnerability on our system and I’m hopeful to not have to edit template files, if possible.
See CVE-2023-48795
According to Red Hat, no patch planned for EL7 due to being “out of support scope”.
It offers a manual mitigation:
If “kex-strict-c-v00@openssh.com” is provided by clients and “kex-strict-s-v00@openssh.com” is in the server’s reply, you use the latest version and are safe, otherwise you may want to disable vulnerable ciphers via crypto policy.
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,aes128-gcm@openssh.com,aes256-gcm@openssh.com MACs umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512
I found similar documentation. I also found steps to resolve by editing the /etc/ssh/ config files to remove the ciphers, which I’ve done for several other servers. On Neth, if I alter the config files, won’t it return later unless I alter a template file? Which file(s) do I need to actually edit?
Maybe wise for the dev team (cc/ @giacomo ) to implement the mitigation through the “Disable weak ciphers” feature available on the UI.
Result with default settings and weak ciphers disabled:
Current settings are implemented through the template /etc/e-smith/templates/etc/ssh/sshd_config/20Encryption:
You can create a copy of the mentioned template (/etc/e-smith/templates/etc/ssh/sshd_config/20Encryption) as a custom template with the desired changes (/etc/e-smith/templates-custom/etc/ssh/sshd_config/20Encryption), but new upstream changes wont make it through.
Another option that shall work would be to use a new fragment template that is processed after the original (ordered by name, like /etc/e-smith/templates-custom/etc/ssh/sshd_config/99custom and /etc/e-smith/templates-custom/etc/ssh/ssh_config/99custom) overriding the former settings. Key exchange should also be customized to mitigate the vuln.
Thanks for the reply. I toyed around with these and adding the custom files had no effect. I double checked files and paths, and I’m unsure why it failed to adjust the /etc/ssh/sshd_config file when either doing a systemctl restart or whole reboot. I also tried editing the ‘live’ file and restarting sshd, and that failed. That led me to notice that the installed version of openssh-server is dreadfully old, v7.4p1 from 2016. It looks like the default repositories don’t have an updated version so my only recourse is to compile the latest release from github.
Has anyone tried that in neth7?
Does ns8 have proxy software in the catalog yet (I didn’t see it listed)?
will have a glance, on todo
@SpiceDenver could you review and test
[[ -z $(ssh -oBatchMode=yes -o StrictHostKeyChecking=yes -vv localhost -p $(config getprop sshd TCPPort) 2>&1|grep -A6 "server KEXINIT proposal"|grep "chacha20-poly1305\|hmac-sha2-[25][51][62]-etm\|hmac-sha1-etm\|hmac-md5-etm") ]] && A="Not v" || A="V";echo $A"ulnerable to CVE-2023-48795"
mkdir -p /etc/e-smith/templates-custom/etc/ssh/sshd_config/
cp -a /etc/e-smith/templates/etc/ssh/sshd_config/20Encryption /etc/e-smith/templates-custom/etc/ssh/sshd_config/
sed -i 's/Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com/Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com/g' /etc/e-smith/templates-custom/etc/ssh/sshd_config/20Encryption
sed -i 's/MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com/MACs umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512/g' /etc/e-smith/templates-custom/etc/ssh/sshd_config/20Encryption
config setprop sshd StrongEncryption enabled
signal-event nethserver-openssh-save
rm -rf /etc/e-smith/templates-custom/etc/ssh/sshd_config/20Encryption
signal-event nethserver-openssh-save
Not vulnerable to CVE-2023-48795
I confirm, it works
Confirmed to remediate. I think I was missing the setprop? Or else I edited the wrong files. Thanks so much!
just the messenger, thank to @Nick @francio87 @filippo_carletti and all the team