Wenn es in der eigenen Umgebung noch alte Systeme gibt, sollte man sicherstellen, dass deren SSHD über Firewalls oder Ähnliches vor Zugriffen von unberechtigten Dritten geschützt werden, um das Problem abzumindern. Es scheint, dass ein Exploit im Durchschnitt viele Login-Versuche benötigt, um ohne weitere Optimierungen erfolgreich zu sein. Dies könnte Administratoren etwas Zeit verschaffen, um heute alles zu patchen, selbst wenn das System bisher über das öffentlichen Internet erreichbar war. Außerdem wurde der Exploit bisher nur für 32-Bit-Systeme gezeigt, auf 64-Bit-Systemen wird ein noch zu entwickelnder Angriff mit hoher Wahrscheinlichkeit langsamer verlaufen (=es werden im Mittel mehr Anmeldeversuche benötigt für einen erfolgreichen Hack).
Sollte man es mit einem System zu tun haben, das aktuell nicht aktualisiert werden kann, könnte es laut der FreeBSD-Sicherheitsmeldung helfen, die Option LoginGraceTime auf 0 zu setzen:
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.
Die Liste ist wahrscheinlich unvollständig und wird ergänzt, je mehr Bestätigungen eingeholt wurden. Am besten startet man den sshd-Dienst nach dem Update neu (z.B. scheint es unter Arch-Linux ansonsten Probleme mit dem Key-Exchange zu geben)
Selbst wenn die eigenen Systeme nicht betroffen zu sein scheinen: Aktualisieren. Jetzt. Es wird viel Forschung zu dieser Schwachstelle geben und möglicherweise werden neue Wege entdeckt, sie auszunutzen.
Nach aktuellem Stand nicht betroffen sind:
Sonstige, weiterführende Links und Berichterstattung:
Aus der Red Hat: CVE-2024-6387-Sicherheitsmeldung: “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.” ↩︎
Siehe https://security-tracker.debian.org/tracker/CVE-2024-6387. ↩︎
Siehe https://www.freebsd.org/security/advisories/FreeBSD-SA-24:04.openssh.asc. Unklare Situation, aber nicht glibc-basiert, und der syslog-Code sieht so aus, als ob er den State nicht beschädigt, wenn er von einem Signal-Handler aufgerufen wird. Im Zweifel patchen. ↩︎
Aus der Qualsys-Meldung: “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.” Außerdem Nicht glibc-basierend. ↩︎