OpenSSH: race condition in sshd allows remote code execution
OpenSSH: race condition in sshd allows remote code execution
A severe vulnerability in OpenSSH, dubbed "regreSSHion" (CVE-2024-6387), has been discovered by the Qualys Threat Research Unit, potentially exposing
cross-posted from: https://lemmy.pt/post/5733711
A severe vulnerability in OpenSSH, dubbed "regreSSHion" (CVE-2024-6387), has been discovered by the Qualys Threat Research Unit, potentially exposing
Worth noting this only affects the portable release of OpenSSH, so OpenBSD (or anyone else using the native release) are unaffected.
musl isn't vulnerable, as per https://fosstodon.org/@musl/112711796005712271
The exploit isn't that practicable, since it takes a very long time on 32 bit systems, which are ever rarer to see.
Question if I update my server and it has the new SSH (patched) package. Is that enough or do I have to restart the server as well? How can I check if the old SSH is in use currently?
For anyone in RHEL / Fedora land (or using dnf somewhere else), try
dnf needs-restartingto list executables that have mismatched files on disk vs memory. The-rflag will hint if a reboot is needed (due to things like kernel or glibc changes)Restart your ssh server to be sure (probably
sudo systemctl restart sshd). No need to reboot your server for this.I don't know how reliable this is, but I usually go into htop to check if stuff needs to be restarted. Processes in red have been replaced or removed since starting.
That said, regular server reboots are a good idea to make sure kernel patches are applied. Can't go wrong with a reboot just in case.
we do restarts twice a month, they are in production