Schwachstelle in OpenSSH und musl libc erlaubt Login ohne Passwort über extrem lange Zeichenkette

Eine Schwachstelle im Zusammenspiel von OpenSSH und der Bibliothek musl libc ermöglicht es einem Angreifer, sich in ein Konto mit deaktiviertem Passwort einzuloggen, indem er über SSH eine Zeichenkette mit einer Länge von 257 bis 1024 Byte sendet. In erster Linie betroffen sind Server mit Alpine Linux, bei denen das Paket openssh-server ohne PAM-Unterstützung gebaut wurde. Für die Ausnutzung genügt eine einzelne Verbindung – der Angriff funktioniert beim ersten Versuch. Ein Fix steht in OpenSSH 10.6p2 und in aktualisierten Alpine-Paketen für die Zweige 3.16 bis 3.24 zur Verfügung. Administratoren betroffener Systeme müssen die Pakete unverzüglich aktualisieren und sshd neu starten oder die Passwortauthentifizierung deaktivieren.

Technische Details der Schwachstelle

Die Schwachstelle trägt die Kennung CVE-2026-123158 – laut Eintrag in der GitHub Advisory Database wurde sie vorläufig als hochgradig kritisch mit einem CVSS-Score von 8.1 bewertet. Dabei ist zu beachten, dass dieser Eintrag den Status „unreviewed“ hat und weder OpenSSH noch Alpine eine eigene CVSS-Bewertung veröffentlicht haben.

Laut Sicherheitshinweis von Alpine Linux müssen für eine erfolgreiche Ausnutzung vier Bedingungen gleichzeitig erfüllt sein:

• Der Server verwendet das Paket openssh-server ohne PAM (oder openssh-server-pam mit UsePAM no);
• Der Parameter PasswordAuthentication ist auf yes gesetzt (Standardwert in OpenSSH);
• Im Passwortfeld des Zielkontos steht in /etc/shadow ein *, das heißt es ist kein Passwort gesetzt (typisch für Accounts, die ausschließlich SSH-Schlüssel verwenden);
• Auf dem System existiert mindestens ein weiteres Benutzerkonto mit einem Passwort-Hash im Format $5$ (SHA-256 crypt) oder $6$ (SHA-512 crypt).

Bemerkenswert ist eine Abweichung zwischen den Quellen hinsichtlich der minimalen Passwortlänge, die die Schwachstelle auslöst: Der Alpine-Sicherheitshinweis nennt 257 Byte, während der Eintrag in der GitHub Advisory Database 256 Byte angibt. Die Obergrenze liegt in beiden Fällen bei 1024 Byte – dies ist eine Beschränkung von sshd selbst.

Mechanismus der Schwachstelle

Das Problem entsteht im Zusammenspiel dreier Komponenten: der Fehlerbehandlung der Funktion crypt() in musl, des Passwortprüfmechanismus in sshd ohne PAM und des Formats der gespeicherten Kontodaten.

Wenn sshd ohne PAM arbeitet, hashed es das eingegebene Passwort selbst mit crypt() und vergleicht das Ergebnis mit dem gespeicherten Wert. Für Konten ohne Passwort steht im Hash-Feld das Zeichen *. Da diese Zeichenkette zu kurz ist, um daraus ein Salt zu extrahieren, leiht sich sshd das Salt von einem anderen Account, der einen echten Hash besitzt. Dieser Mechanismus zum „Ausleihen“ eines Salts wurde 2016 eingeführt, um die Schwachstelle CVE-2016-6210 zu beseitigen, die es erlaubte, aus der Antwortzeit des Servers auf existierende Benutzernamen zu schließen.

Der entscheidende Punkt ist das Verhalten von musl: Bei der Verarbeitung von $5$– und $6$-Hashes weigert sich die Funktion crypt(), mit Passwörtern zu arbeiten, die länger als 256 Byte sind, und gibt als Fehlerindikator * zurück. Diese Entscheidung wurde 2012 getroffen – anstelle von NULL bei einem Fehler zurückzugeben, liefert musl einen „nicht übereinstimmenden Hash“, da viele Programme NULL nicht überprüften. Der zurückgegebene Wert * entspricht jedoch genau dem, was in /etc/shadow für Konten ohne Passwort gespeichert wird, und sshd wertet die Prüfung als erfolgreich.

Bemerkenswert ist, dass die Entwickler von OpenSSH und musl die Ursachen unterschiedlich bewerten. Laut den Release Notes zu OpenSSH 10.6p2 sieht das OpenSSH-Team die Wurzel des Problems außerhalb von sshd, auch wenn sich die Ausnutzbarkeit auf dessen Seite verhindern lässt. Der musl-Entwickler Rich Felker wiederum weist darauf hin, dass das Problem im Umgang der aufrufenden Applikation mit dem Rückgabewert von crypt() liegt.

Umfang der Auswirkungen

Betroffen sind alle Versionen von Alpine Linux von 3.16 bis 3.24 sowie der Zweig edge, sofern die oben beschriebene Konfiguration vorliegt. Systeme auf Basis von glibc sowie alle Konfigurationen mit aktiviertem PAM sind nicht verwundbar.

Besondere Aufmerksamkeit verdienen Cloud-Images von Alpine auf Basis von tiny-cloud in den Versionen 3.18.11 bis 3.24.3. Darin existiert das Konto alpine mit dem Passwortfeld * und dem Recht, Befehle über doas ohne Passwort auszuführen. Solche Images sind beim ersten Start sicher, werden aber verwundbar, sobald im System mindestens ein Hash im Format $6$ vorhanden ist – etwa nachdem ein Administrator ein Passwort für den Konsolenzugang gesetzt hat. In diesem Fall kann sich ein Angreifer als alpine anmelden und sich über doas Root-Rechte verschaffen.

Das Root-Konto ist standardmäßig durch die Einstellung PermitRootLogin prohibit-password geschützt, was jedoch nicht hilft, wenn ein kompromittiertes Konto über Möglichkeiten zur Rechteausweitung verfügt.

Hinsichtlich anderer Systeme auf musl – der Forscher Özgün Kültekin von der Firma Wakefield, der die Schwachstelle entdeckt hat, nennt OpenWrt, Buildroot und Yocto als Plattformen, die überprüft werden sollten. Der praktische Einschlagradius ist jedoch kleiner, als es zunächst erscheinen mag: Das Standard-OpenWrt verwendet Dropbear als SSH-Server, wie aus der OpenWrt-Dokumentation hervorgeht, und Dropbear ist für diese Schwachstelle nicht anfällig. Für OpenWrt ist das Problem nur dann relevant, wenn OpenSSH vom Administrator manuell installiert wurde.

Ein öffentlicher PoC zur Reproduktion der Schwachstelle ist bereits verfügbar, allerdings lagen zum Zeitpunkt der Veröffentlichung keine Berichte über eine Ausnutzung in realen Angriffen vor.

Empfehlungen zur Behebung

Laut dem Sicherheitshinweis von Alpine sind folgende Schritte erforderlich, um die Schwachstelle zu beseitigen:

1. Pakete aktualisieren: apk upgrade -U -a
2. sshd neu starten: rc-service sshd restart – das Paket-Update startet den laufenden sshd-Prozess nicht automatisch neu.

Die korrigierten Pakete sind in die Point-Releases Alpine 3.21.10, 3.22.8, 3.23.8 und 3.24.4 eingeflossen. Die Zweige 3.16–3.20, die bereits aus dem regulären Support herausgefallen sind, haben ebenfalls Fixes erhalten.

Bei eigener Kompilierung von OpenSSH sollte auf Version 10.6p2 aktualisiert werden, die einen Workaround enthält – sshd verwirft nun eine Übereinstimmung, wenn das gespeicherte Passwortfeld kürzer als vier Zeichen ist.

Wenn ein sofortiges Update nicht möglich ist, muss die Passwortauthentifizierung deaktiviert werden:

• Sicherstellen, dass der Login per SSH-Schlüssel funktioniert, und die aktuelle Session nicht schließen, bevor der neue Zugriff getestet wurde;
• PasswordAuthentication no in der sshd-Konfiguration setzen;
• Die Konfiguration prüfen: sshd -t;
• sshd neu starten;
• Das Ergebnis prüfen: sshd -T | grep -i passwordauthentication sollte passwordauthentication no ausgeben.

Zur Erkennung einer möglichen Kompromittierung empfiehlt der Alpine-Sicherheitshinweis, /var/log/messages auf Einträge des Typs Accepted password for für Konten ohne Passwort zu prüfen – etwa für alpine, root oder Accounts, die ausschließlich Schlüssel verwenden. Auf potenziell kompromittierten Systemen sollten außerdem die Nutzung von doas, kürzlich angelegte Benutzer, Dateien und autorisierte Schlüssel untersucht werden. Wie im Hinweis formuliert: „Wenn Sie einen Login nicht ausschließen können, betrachten Sie die Maschine als kompromittiert.“

Administratoren von Alpine Linux mit aktiviertem SSH-Zugang sollten Pakete aktualisieren und sshd vorrangig auf Cloud-Instanzen von tiny-cloud in den Versionen 3.18.11–3.24.3 neu starten, da die Kombination aus Schwachstelle und doas-Rechten hier einen direkten Weg zu Root-Rechten eröffnet. Auf allen anderen betroffenen Systemen richtet sich die Priorität des Updates nach dem Vorliegen der vier beschriebenen Bedingungen – wenn mindestens eine davon nicht erfüllt ist, ist das System für diesen Angriff nicht anfällig.