OpenSSH: Weitere RegreSSHion-artige LĂĽcke entdeckt
Die RegreSSHion-Lücke ermöglichte Angreifern Root-Zugriff. Ein IT-Forscher hat eine weitere ähnliche Lücke in OpenSSH von RHEL 9 und Abkömmlingen entdeckt.
(Bild: Bild erstellt mit KI in Bing Designer durch heise online / dmk)
Eine in der vergangenen Woche bekannt gewordene Sicherheitslücke in OpenSSH ermöglichte Angreifern einen Brute-Force-Angriff, an dessen Ende eine root-Shell wartete. Auf Basis dieser "RegreSSHion" (CVE-2024-6387) getauften Lücke hat ein IT-Forscher weitergesucht und wurde fündig: Eine weitere ähnliche Schwachstelle schlummert im Code der Software für sichere Zugänge, insbesondere von Red Hat Enterprise Linux.
Bei der neuen Schwachstelle lautet die Beschreibung: Eine Race Condition kann in einem Signal-Handler von OpenSSH auftreten, sofern ein Client sich nicht in der "LoginGraceTime" authentifiziert – 120 Sekunden standardmäßig, in älteren OpenSSH-Versionen 600 Sekunden. In dem Fall wird der SIGALRM-Handler des sshd asynchron aufgerufen. Dieser ruft wiederum diverse Funktionen auf, die ihrerseits nicht "async-signal-safe" sind, etwa syslog(). Dies führe zu einer Signal-Handler-Race-Condition in der cleanup_exit()-Funktion. Das münde in dieselbe Schwachstelle im unprivilegierten Child-Prozess des sshd-Servers wie CVE-2024-6387. Im schlimmsten Fall können Angreifer Code aus dem Netz ausführen, im Nutzerkontext des OpenSSH-Servers, mit niedrigen Rechten (CVE-2024-6409, CVSS 7.0, Risiko "hoch").
Nur wenige Linux-Distributionen betroffen
Eine ganz deutliche Einschränkung folgt: Diese Lücke betreffe ausschließlich den sshd-Server, der mit Red Hat Enterprise Linux 9 ausgeliefert werde. Die Upstream-Versionen sind demnach nicht von dem Fehler betroffen. Etwas detaillierter ist die Meldung der Sicherheitslücke oder der OSS-Security-Mailingliste. Dort wird erläutert, dass OpenSSH 8.7 und 8.8 die cleanup_exit()-Funktion aus dem grace_alarm_handler() heraus aufrufen, wobei cleanup_exit() nie dafür gedacht war, aus einem Signal-Handler heraus aufgerufen zu werden, sie sei eben nicht async-safe.
Downstream-Patches führten jedoch gelegentlich zu solchen async-unsafe-Funktionsaufrufen. Im Red-Hat-OpenSSH-Paket sei der openssh-7.6p1-audit.patch zu finden, der dieses fehlerhafte Verhalten einführe. Insbesondere in RHEL 9 und entsprechenden Rebuilds oder Downstream-Distributionen, in denen OpenSSH auf 8.7p1 basiere, sei der Patch zu finden. Aber auch Fedora ist betroffen, in Paketen basierend auf OpenSSH 8.7p1 sowie 8.8p1. Das beschränke sich jedoch auf Fedora 36 und 37, sowie einige Aktualisierungen für Fedora 35 bis 37 können das mitgebracht haben. Diese seien jedoch am End-of-Life (EoL) angelangt und Fedora 38 und neuer sind auf neueren Upstream-OpenSSH umgestiegen.
Der Hauptunterschied zur "RegreSSHion"-Lücke sei, dass die Race-Condition in einem rechteseparierten Child-Prozess ausgelöst werde, der mit niedrigeren Rechten laufe im Vergleich zum Eltern-Prozess. Die unmittelbaren Auswirkungen seien damit geringer. Die Ausnutzbarkeit in gewissen Szenarien könne jedoch für Angreifer interessant sein. Temporäre Gegenmaßnahmen wie das Setzen der LoginGraceTime auf 0 Sekunden helfen demnach gegen beide Schwachstellen. Die "-e"-Gegenmaßnahme helfe hingegen vollständig gegen CVE-2024-6387, jedoch nur eingeschränkt gegen CVE-2024-6409. Ein Exploit gegen die neue Lücke wurde jedoch noch nicht versucht und die Ausnutzbarkeit ist damit noch nicht bewiesen. Wie bei der RegreSSHion-Lücke hätten die IT-Sicherheitsforscher von Qualys die Lücke jedoch bestätigt und analysiert.
Admins sollten bereitstehende aktualisierte OpenSSH-Pakete fĂĽr RHEL und davon abgewandelte Linux-Distributionen installieren. Oder zumindest bis dahin die vorgeschlagene GegenmaĂźnahme mit dem Herabsetzen der LoginGraceTime umsetzen.
Anfang vergangener Woche wurde die "RegreSSHion"-Schwachstelle bekannt. Sie erlaubt Angreifern, Brute-Force-Angriffe auszufĂĽhren, die in rund acht Stunden in einen Zugang mit root-Rechten mĂĽnden.
(dmk)