OpenSSH-SicherheitslĂĽcke: regreSSHion (CVE-2024-6387), Remote Code Execution (RCE)

·3 min·Andreas Haerter·

Heute ist eine Aktualisierung aller OpenSSH-Server angesagt, komme was wolle. Die originale Sicherheitswarnung von Qualys ist lesenswert und nicht allzu kompliziert, um sie nachzuvollziehen, sofern man an den HintergrĂĽnden interessiert ist. Ein “kleines” Problem könnte sein, dass dieser Fehler buchstäblich am Tag nach dem Support-Ende von CentOS 8 und FreeBSD 13.2 entdeckt wurde (auch wenn beide wohl aktuell nicht betroffen sind).

Mitigation

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.

Betroffene Systeme

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)

Wahrscheinlich nicht betroffen Systeme

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:

  • Red Hat Enterprise Linux (RHEL) 6, 7 und 81 (und daher wohl auch alle verwandten CentOS-Versionen)
  • Debian 11 Bullseye2
  • FreeBSD3
  • OpenBSD4

Sonstige, weiterfĂĽhrende Links und Berichterstattung:


  1. 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.” ↩︎

  2. Siehe https://security-tracker.debian.org/tracker/CVE-2024-6387↩︎

  3. 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. ↩︎

  4. 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. ↩︎