Nach traditionellen Sicherheitsgrundsätzen kann ein vom Betriebssystem gesperrtes Benutzerkonto unter keinen Umständen zur Anmeldung genutzt werden. Jedes eingegebene Passwort müsste unweigerlich abgewiesen werden. Am 5. November 2026 erschütterte ein Sicherheitshinweis der leichtgewichtigen Linux-Distribution Alpine Linux diesen Grundsatz nachhaltig.
Ein Angreifer musste lediglich ein Passwort mit mehr als 256 Bytes übermitteln, und das gesperrte Administratorkonto stand sperrangelweit offen. Der gesamte Vorgang erforderte weder Speicherbeschädigungen noch Brute-Force-Angriffe auf Passworthashes. Der Abwehrmechanismus glich das eingegebene Passwort mit dem Sperrkennzeichen ab und gewährte die Verbindung vollkommen regulär.
Dieses anomale Verhalten resultierte aus dem unerwarteten Zusammenspiel dreier unabhängiger Sicherheitsvorkehrungen. Wenn ein Fehlersignal für eine fehlgeschlagene Berechnung und der Kontostatus für ein Anmeldeverbot dasselbe Zeichen verwenden, bricht die Authentifizierungslogik an ihrer Schnittstelle zusammen.
Drei Schutzmechanismen greifen ineinander: 257 Zeichen hebeln die Sperre aus
In der Unix-Shadow-Datei /etc/shadow kennzeichnet ein Sternchen * seit Jahrzehnten gesperrte Benutzerkonten. Befindet sich im Passwortfeld ein einzelnes Sternchen, betrachtet das System die Passwortauthentifizierung als deaktiviert. Da reguläre Passworthashes aus Dutzenden Zeichen bestehen, ist eine zufällige Übereinstimmung mit einem einzelnen Sternchen praktisch ausgeschlossen.
Um Zeitangriffe zu verhindern, bei denen Angreifer gültige Benutzernamen anhand von Antwortzeiten ermitteln, entwickelten OpenSSH-Ingenieure einen Schutzmechanismus. Besitzt ein Konto kein gültiges Passwort, bricht der Dienst nicht sofort ab. Stattdessen entleiht er das Salt eines anderen legitimen Kontos und führt eine ähnlich zeitaufwendige Pseudo-Hash-Berechnung durch. Dadurch bleibt die Antwortzeit des Servers unabhängig von der Existenz des Kontos konstant.
Gleichzeitig setzt die leichtgewichtige C-Bibliothek musl eigene Schutzgrenzen. Um Speichererschöpfung durch böswillig lange Eingaben zu unterbinden, definiert die crypt()-Funktion von musl eine strikte Obergrenze. Überschreitet das eingegebene Passwort 256 Bytes, bricht die Funktion die Berechnung sofort ab. Als Fehlersignal gibt sie einen Zeiger auf ein statisches Sternchen * zurück.
Für sich genommen folgt jeder dieser drei Mechanismen einer fundierten Sicherheitsphilosophie. Doch sobald sie im selben System zusammenwirken, entsteht unbemerkt ein offenes Einfallstor.
Ein Angreifer muss lediglich vier Voraussetzungen erfüllen:
- Den SSH-Port des Zielsystems erreichen;
- Ein Konto vorfinden, dessen Passwortfeld in der Shadow-Datei ein
*enthält (etwa der Standard-Root-Account in Alpine seit Version 3.16); - Mindestens ein weiteres legitimes Benutzerkonto im System vorfinden, das einen regulären
$5$- oder$6$-Hash nutzt; - Ein überlanges Passwort mit einer Länge zwischen 257 und 1024 Bytes übermitteln.
Kommen diese vier Bedingungen zusammen, nimmt OpenSSH das überlange Passwort und startet die Pseudo-Berechnung mit dem entliehenen Salt. Die musl-Bibliothek bricht wegen der Längenbegrenzung ab und liefert den Fehlerindikator *. OpenSSH vergleicht diesen Rückgabewert mit dem Passwortfeld in der Shadow-Datei – beide Seiten ergeben ein einzelnes Sternchen. Der Vergleich meldet Übereinstimmung, und der gesperrte Zugang wird freigegeben.
Abbildung: Der offizielle Sicherheitshinweis von Alpine Linux zur Authentifizierungsumgehung ohne PAM. Quelle: alpinelinux.org.
Ein Sternchen mit zwei Bedeutungen: Kontosperre trifft Fehlerwert
Der Kern dieser Schwachstelle liegt im semantischen Konflikt über verschiedene Softwareschichten hinweg. Die übergeordnete Anwendung betrachtet das Sternchen als unüberwindbares Schloss, während die zugrundeliegende Bibliothek es als Fehlersignal zurückgibt.
In klassischen Unix-Implementierungen gaben kryptografische Funktionen bei ungültigen Eingaben meist einen Null-Zeiger zurück. Aufrufender Code konnte anhand einer Null-Prüfung einfach zwischen Erfolg und Fehlschlag unterscheiden. Allerdings führten Null-Zeiger in älteren Programmen häufig zu Dereferenzierungsabstürzen. musl folgte daher einem Standard, der im Fehlerfall einen Zeiger auf ein statisches Zeichen * zurückgibt.
Dieser Entwurf setzte voraus, dass der Aufrufer das Sternchen als ungültigen Hash interpretiert. Unter normalen Umständen funktionierte dies reibungslos: Selbst wenn eine Eingabe ein Sternchen als Ergebnis lieferte, wiesen reguläre Konten vollständige Hashes auf, wodurch eine Übereinstimmung ausgeschlossen blieb.
Erst die Pseudo-Salt-Logik von OpenSSH schloss die verhängnisvolle Kette. In minimalistischen Umgebungen ohne PAM prüft der OpenSSH-Daemon Passwörter eigenständig. Um Zeitmessungen von Angreifern zu vereiteln, führte OpenSSH die Hash-Berechnung auch für gesperrte Konten durch.
Damit geriet der Prüfpfad in eine Falle. OpenSSH ging davon aus, ein echtes Passwort zu validieren, während die C-Bibliothek die Berechnung längst abgebrochen hatte. Eine feine Diskrepanz in der Schnittstellensemantik verwandelte das Sperrkennzeichen in einen Generalschlüssel.
Verstecktes Risiko in Cloud-Images: Ein zusätzliches Konto öffnet die Hintertür
Nach der Veröffentlichung untersuchte die Fachwelt die praktische Tragweite. Nicht jede Alpine-Installation ist automatisch verwundbar; das reale Risiko hängt von der konkreten Konfiguration ab.
Schlanke Container, die lediglich isolierte Mikrodienste ausführen, haben selten einen SSH-Port geöffnet und sind somit geschützt. Server, auf denen die Passwortauthentifizierung deaktiviert ist (PasswordAuthentication no), bleiben ebenfalls immun. Systeme mit PAM-Modulen wickeln die Prüfung über separate Module ab, sodass der fatale String-Vergleich nicht auftritt.
Die eigentliche Falle verbarg sich in Cloud-Vorlagen. Die offiziellen tiny-cloud-Images von Alpine zwischen den Versionen 3.18.11 und 3.24.3 richteten standardmäßig ein Benutzerkonto namens alpine ein. Dessen Passwortfeld in /etc/shadow war auf * gesetzt, begleitet von passwortlosen Sudo-Rechten.
Auf einer frisch aufgesetzten Instanz war dieses Konto zunächst sicher: Da kein weiteres Benutzerkonto mit einem Passworhashe existierte, konnte OpenSSH kein Salt entleihen und aktivierte die Pseudo-Berechnung nicht. Viele Administratoren wiegten sich daher in falscher Sicherheit.
Die Schwachstelle zündete in dem Moment, in dem der Administrator das erste reguläre Benutzerkonto anlegte. Sobald für eine Anwendung ein Standardbenutzer mit Passworthash in die Shadow-Datei eingetragen wurde, verwandelte sich das schlummernde alpine-Konto in eine Hintertür. Ein Angreifer konnte sich mit einem 257-Byte-Passwort einloggen und umgehend Root-Rechte erlangen.
Update erfordert Daemon-Neustart: Deaktivierung der Passwortanmeldung als Sofortmaßnahme
Für die Schwachstelle wurde bei der Veröffentlichung keine separate CVE-Nummer vergeben. Der Sicherheitsforscher Özgün Kültekin entdeckte die Anomalie, woraufhin die Teams von OpenSSH und Alpine rasch Patches bereitstellten. Die Korrektur wurde in den Versionshinweisen zu OpenSSH 10.6p2 dokumentiert und für Alpine 3.16 bis 3.24 sowie den edge-Zweig bereitgestellt.
Betroffene Systeme sollten umgehend die Paketquellen aktualisieren und Patches einspielen. Mit dem Befehl apk upgrade -U -a wird OpenSSH auf die bereinigte Version aktualisiert. Der korrigierte Code prüft zurückgegebene Sonderzeichen streng und schließt semantische Verwechslungen aus.
Abbildung: Release Notes zu OpenSSH 10.6p2 mit Details zur Korrektur bei überlangen Passwörtern und Pseudo-Salts. Quelle: openssh.com.
Entscheidend ist: Der Austausch der Binärdateien auf der Festplatte beseitigt die Gefahr noch nicht. Der alte Daemon verbleibt im Arbeitsspeicher aktiv und bleibt angreifbar. Nach dem Update müssen Administratoren zwingend rc-service sshd restart ausführen, um den neuen Code im Speicher zu aktivieren.
Für Produktivserver, die nicht sofort neu gestartet werden können, empfiehlt sich die Abschaltung der Passwortanmeldung. In /etc/ssh/sshd_config.d/00-no-passwords.conf wird die Direktive PasswordAuthentication no hinterlegt, die Konfiguration geprüft und der Dienst neu geladen. Mit sshd -T lässt sich die Deaktivierung verifizieren. Bei der Analyse älterer Protokolle deuten erfolgreiche Logins passwortloser Konten in /var/log/messages auf einen möglichen Einbruch hin.
Sicherheitslücken entstehen oft an den Schnittstellen verschiedener Softwareschichten. Wenn jede Komponente für sich bewährte Sicherheitsmuster befolgt, sich jedoch bei der Definition grundlegender Schnittstellensymbole geringfügig unterscheidet, kann das Gesamtsystem von innen kollabieren. Eindeutige und unveränderliche Semantik an Systemschnittstellen ist ein weit grundlegenderes Ingenieursprinzip als das bloße Anhäufen von Schutzmechanismen.
Weiterführende Links:
- Alpine Linux Sicherheitshinweis
- OpenSSH 10.6p2 Release Notes
- Technische Diskussion auf Lobsters
