If there are old boxes, make sure you apply proper firewalling to mitigate the issue. It seems that a exploit might need a lot of login tries on average to be successful without further optimizations. This might buy you a bit of time to patch everything today, even if the box was exposed to the public internet. Additionally, the exploit was only shown for 32-bit systems yet. There is a high probability that a yet-to-come exploit for 64-bit systems will be slower (=more login attempts needed on average for a successful hack).
If you cannot upgrade your system yet, the FreeBSD security advisory states that setting LoginGraceTime to 0 might help:
If sshd(8) cannot be updated, this signal handler race condition can be mitigated by setting LoginGraceTime to 0 in /etc/ssh/sshd_config and restarting sshd(8). This makes sshd(8) vulnerable to a denial of service (the exhaustion of all MaxStartups connections), but makes it safe from the remote code execution presented in this advisory.
The list is probably incomplete and will be updated as more confirmations are obtained. Do not forget to restart the sshd service (for example, it seems that there are otherwise issues with key exchange on Arch Linux).
Even if your systems seem to be not affected in general: Update. Now. There will be a lot of research about this vulnerability and maybe new ways to exploit it will be discovered.
Currently not affected are:
Additional links and reports:
From the Red Hat: CVE-2024-6387 advisory: “This flaw doesn’t affect the OpenSSH versions as shipped with Red Hat Enterprise Linux 6, 7 and 8 as the vulnerability was introduced by a regression in upstream on OpenSSH 8.5p1 which is newer then shipped with the mentioned Red Hat Enterprise Linux versions.” ↩︎
See https://security-tracker.debian.org/tracker/CVE-2024-6387. ↩︎
See https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc. Unclear situation but not glibc based and the syslog code looks as if it doesn’t do anything that corrupts the state if called from a signal handler. Patch in doubt. ↩︎
From the Qualsys advisory: “OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.” Additionally, not glibc based. ↩︎