Am 5. November 2026 wurde im Linux-Ökosystem eine Sicherheitslücke offengelegt, die gängigen kryptographischen Grundsätzen widerspricht. In Millionen von Alpine-basierten Containern wurden Administratorkonten kompromittiert, bei denen die Passwortauthentifizierung eigentlich vollständig deaktiviert war. Angreifern genügte es, eine beliebige Zeichenfolge aus 257 Zeichen in die Passwortmaske einzugeben, um unmittelbaren Systemzugriff zu erlangen.
Nach allgemeinem Verständnis gilt ein Passwort als umso sicherer, je länger es ist; überlange Eingaben sollten von Schutzmechanismen abgefangen werden. Doch die Realität kehrte dieses Prinzip um: Eine strikte Zugangskontrolle wurde durch eine Kette zufälliger Tastatureingaben mühelos aufgestoßen.
Überlange Eingabe bricht Abwehr: Zugriff mit 257 Zeichen
Die Bedingungen zur Auslösung der Schwachstelle sind präzise und erstaunlich verbreitet. Der Zielserver muss einen OpenSSH-Dienst ausführen, der gegen die C-Bibliothek musl gelinkt ist und kein PAM verwendet. Übermittelt ein Angreifer ein Passwort mit einer Länge zwischen 257 und 1024 Bytes, wird die Authentifizierung umgehend gewährt.
257 Bytes übersteigen die übliche Passwortlänge bei weitem. Doch diese anomalen Daten durchdrangen die Abgleichslogik, woraufhin das System ein für Passwörter gesperrtes Konto als erfolgreich verifiziert einstufte. In diesem kritischen Moment versagte die Sicherheitsarchitektur.
Die betroffenen Konten weisen ein klares Merkmal auf: In der Datei /etc/shadow enthält ihr Passwortfeld lediglich das einzelne Zeichen *. Gemäß UNIX-Konvention signalisiert ein Asterisk, dass für dieses Konto niemals Passwörter akzeptiert werden. Standard-Images von Cloud-Anbietern sowie Deployment-Konten, die rein auf SSH-Schlüsseln basieren, sind typischerweise so konfiguriert.
Die am leichtesten erreichbaren Ziele liegen in der Cloud: Der Standardbenutzer alpine in den offiziellen AWS- und Azure-Images von Alpine Linux nutzt exakt dieses Setup und verfügt zudem über passwortlose doas-Rechte. Die Kompromittierung dieses Kontos entspricht direkt dem Erlangen von Root-Rechten.
Sobald auf dem System ein weiteres Konto mit einem regulären Passworthash existiert, lässt sich der Angriff deterministisch reproduzieren. OpenSSH greift auf das Salt dieses Kontos zurück, um Timing-Angriffe abzuwehren. Mehrere Sicherheitsvorkehrungen griffen ineinander – und öffneten am Ende ungewollt die Tür für unbefugten Zugriff.
Drei vernünftige Entscheidungen kollidieren nach 46 Jahren
Blickt man in die Entwicklungsgeschichte von UNIX, so entstand diese Hintertür aus drei unabhängigen Entwurfsentscheidungen, die über Jahrzehnte auseinanderlagen. Jede einzelne Entscheidung war zu ihrem Entstehungszeitpunkt wohlüberlegt und zweckmäßig; ihr Zusammenspiel erwies sich jedoch als fatal.
Die erste Entscheidung fiel im Jahr 1980. Bill Joy trug im Passwortverzeichnis des 3BSD-Systems für das Dienstkonto daemon ein * ein. Da damalige Hash-Algorithmen kein einzelnes Sternchen als Ausgabe erzeugen konnten, konnte keine eingegebene Zeichenkette jemals damit übereinstimmen.
Abbildung: Screenshot der originalen passwd-Datei von 3BSD aus dem Jahr 1980, in der das Passwortfeld des Kontos daemon mit einem Sternchen versehen ist. Quelle: sshhole.com
Diese einfache Konvention, Konten mittels eines Sternchens zu sperren, hielt sich über 46 Jahre hinweg als Industriestandard für nicht anmeldbare Konten.
Die zweite Entscheidung folgte 1997. Der Single-UNIX-Standard legte fest, dass die Verschlüsselungsfunktion crypt() bei Rechenfehlern einen NULL-Zeiger zurückgeben sollte. Viele C-Programme prüften jedoch Rückgabewerte nicht auf NULL, was zu Speicherzugriffsfehlern (Segmentation Faults) und Abstürzen von Hintergrunddiensten führte.
Im August 2012 reagierten die Entwickler der leichtgewichtigen C-Bibliothek musl auf dieses Problem. Um Abstürze durch Null-Zeiger abzuwenden, änderte Commit b3c4cc12 das Verhalten so ab, dass bei Berechnungsfehlern ein einzelnes * zurückgegeben wurde. Frühere Kommentare, wonach Fehler unmöglich seien, wurden dabei gestrichen.
Abbildung: Header-Kommentare in musl, die festhalten, dass bei Fehlern während der Berechnung ein einzelnes Sternchen zurückgegeben wird. Quelle: sshhole.com
Für die musl-Entwickler bedeutete der Asterisk einen Rechenfehler. Für Systemadministratoren bedeutete der Asterisk ein Anmeldeverbot. Zwei Gruppen maßen demselben Zeichen eine völlig gegensätzliche Semantik bei.
DoS-Puffergrenze trifft auf Timing-Side-Channel-Schutz
Die dritte Entscheidung schlug die Brücke zwischen den beiden Sternchen. Am 29. August 2012 – lediglich zwanzig Tage nach der vorherigen Änderung – ergänzte musl die Unterstützung für das Hashing-Verfahren SHA-512.
SHA-512 ist rechenintensiv, und der Aufwand steigt mit der Länge der Eingabe. Um Server vor Denial-of-Service-Angriffen durch überlange Eingaben zu schützen, setzte musl eine strikte Obergrenze von 256 Bytes für Passwörter fest. Überstieg die Eingabe diese Grenze, verweigerte die Funktion die Berechnung und lieferte als Fehler ein einzelnes * zurück.
Abbildung: musl libc setzt in crypt_sha512.c ein Limit von 256 Bytes durch, um Ressourcenerschöpfung auf Servern zu verhindern. Quelle: sshhole.com
Dieses 256-Byte-Limit wehrte DoS-Angriffe erfolgreich ab und arbeitete jahrelang unbemerkt im System.
Im Juli 2016 behob OpenSSH die Schwachstelle CVE-2016-6210, bei der Antworten für nicht existente Benutzer schneller erfolgten, was das Ausspähen gültiger Benutzernamen über Zeitmessungen ermöglichte. Um diese Zeitunterschiede zu nivellieren, führte OpenSSH Dummy-Berechnungen ein.
Erhält OpenSSH eine Anmeldeanfrage für ein Konto ohne gültigen Passworthash, leiht sich das System das Salt eines existierenden Kontos und führt eine Scheinberechnung durch, um künstlich Zeit zu verbrauchen. Auch gesperrte Konten, deren Passwortfeld ein Sternchen enthielt, durchliefen fortan diesen Berechnungspfad.
Damit schloss sich die Kette: Ein Angreifer sendet ein 257 Byte langes Passwort an das Root-Konto. OpenSSH leiht sich ein Salt und ruft crypt() auf. musl erkennt die Überschreitung des 256-Byte-Limits, bricht ab und liefert ein * zurück. OpenSSH vergleicht dieses * mit dem Eintrag in /etc/shadow. Beide Werte stimmen exakt überein – und das System gewährt sofortigen Zugang.
Container-Boom bringt Nischendesign auf Millionen Cloud-Instanzen
musl fand ursprünglich vor allem in Routern und eingebetteten Systemen Verwendung, wo die Angriffsfläche naturgemäß begrenzt war. Der Siegeszug von Containern katapultierte dieses Design jedoch direkt in das Zentrum moderner Cloud-Architekturen.
Mit einer Image-Größe von lediglich 5 MB entwickelte sich Alpine Linux zum weltweiten Standard-Basisimage für Container. Als 2019 das leere Root-Passwort in offiziellen Images behoben wurde, sperrte man das Konto vorübergehend mit einem Ausrufezeichen !. Dies blockierte jedoch die SSH-Schlüsselauthentifizierung in Umgebungen ohne PAM und störte Anmeldungen auf Cloud-Instanzen empfindlich.
Im Jahr 2022 machte Alpine 3.16 diese Änderung rückgängig und setzte das Root-Passwortfeld wieder auf ein *. Die Anmeldung per Public-Key funktionierte wieder – doch gleichzeitig waren damit alle künftigen Container und Images anfällig für die Umgehung der Authentifizierung.
Die Entwickler-Community analysierte umgehend das Schadensausmaß. Der Entwickler jbyers betonte, dass die Wahrscheinlichkeit für das Eintreffen aller Bedingungen bei einem einzelnen Container zwar moderat erscheine, hochgerechnet auf die weltweite Gesamtmasse an Instanzen jedoch eine erschreckende Zahl betroffener Systeme ergebe. Millionen produktiver Container liefen unbemerkt in diese Falle.
Auch über die Einhaltung von Standards entbrannte eine Debatte. Entwickler NewJazz hinterfragte, ob musl von der POSIX-Spezifikation abgewichen sei. Andere verwiesen auf den POSIX-Text und hielten dagegen, dass der Standard lediglich einen einzigen Fehlercode definiere und es an klaren Vorgaben für Ausnahmebehandlungen schlicht fehle.
Auf der Plattform Lobsters kritisierte der Nutzer mort den dramatischen Tonfall von Sicherheitsberichten: Veröffentlichungen sollten pragmatisch bleiben und sich auf Schadensausmaß sowie konkrete Gegenmaßnahmen konzentrieren.
Paket-Update reicht nicht aus: Dienste müssen sofort neu starten
Am 5. November 2026 veröffentlichte das OpenSSH-Projekt die Version 10.6p2. Der Patch enthält eine explizite Filterregel gegen einstellige Rückgabewerte, sodass sich die Anwendungsebene nicht mehr blind auf die Konventionen der Systembibliothek verlässt.
Die Aktualisierung des Softwarepakets allein reicht jedoch nicht aus. Die Art und Weise, wie Linux laufende Prozesse im Speicher hält, führt bei vielen Administratoren zu gefährlichen Missverständnissen.
Zwar ersetzt der Paketmanager die Dateien auf dem Datenträger, im Arbeitsspeicher verbleibende Daemons führen jedoch weiterhin den alten Code aus. Solange die Dienste nicht neu gestartet werden, bleibt das System verwundbar. Administratoren müssen den sshd-Dienst unverzüglich neu starten oder betroffene Container neu erstellen.
Rückblickend betrachtet war keine einzige Codezeile dieser Schwachstelle böswillig motiviert. 1980 sperrte man Konten mit einem Sternchen, 1997 definierte man Rückgabewerte gegen Abstürze. 2012 begrenzte man Längen gegen Denial-of-Service und 2016 glättete man Antwortzeiten gegen Timing-Angriffe. Jede dieser Entscheidungen war in ihrem zeitlichen Kontext vollkommen legitim.
Doch über vier Jahrzehnte hinweg trafen diese Schutzmechanismen aufeinander. Eine minimale semantische Diskrepanz schuf eine verdeckte Privilege-Escalation-Lücke. In komplexen Systemen bergen gestaffelte, sich gegenseitig missverstehende Abwehrmechanismen oft weit größere Gefahren als isolierte Programmierfehler.
Weiterführende Links:
- sshhole.com Originaler Schwachstellenbericht und Online-Prüftool
- Alpine aports Commit fbe926af: Umstellung des Root-Passwortfelds von Ausrufezeichen auf Sternchen
- OpenSSH 10.6p2 Offizielle Release-Mitteilung und Quellcode-Patch
- Diskussion auf Hacker News zu Fehlerrückgabewerten von musl crypt
- Lobsters-Debatte über Containersicherheit und Gegenmaßnahmen
