Der Stern kam zurück: Wie ein Unix-Marker von 1980 zu einem SSH-Bypass von 2026 wurde

Am 5. November veröffentlichte das OpenSSH-Team 10.6p2, als kritisch eingestuft, für einen Login-Bypass, der keinen Exploit-Code, keine Speicherkorruption und keine clevere Payload braucht. Du sendest ein Passwort mit mehr als 256 Zeichen an ein Konto, das überhaupt kein Passwort hat. Du kommst rein.

Der Fehler lebt nicht in einer vergessenen Ecke des Internets. Er lebt in Alpine Linux und damit in einem sehr großen Anteil der Container-Images, die dein Team jede Woche herunterlädt. Wenn du einen nur-schlüsselbasierten Deploy-User auf einem Alpine-Host hast, bei dem Passwort-Authentifizierung im Standardwert gelassen wurde, ist dieses Konto nicht mehr nur-schlüsselbasiert.

Hier ist der Teil, der deine Aufmerksamkeit verdient: die gefährdeten Konten sind die, die du gehärtet hast.

Was wirklich auf dem Draht passiert

Ohne PAM prüft sshd Passwörter selbst. Es nimmt den Versuch, hasht ihn mit crypt() und vergleicht das Ergebnis mit dem gespeicherten Feld in /etc/shadow. Ein normales Konto speichert etwas wie $6$abc$k2P9...: einen Algorithmus-Marker, ein Salt, einen Hash.

Ein Konto ohne Passwort speichert ein einziges *. Dieser Marker ist kein Hash und kein Passwort kann je mit ihm übereinstimmen. So ist es seit 1980, als Bill Joy ein * in das Passwortfeld des daemon-Kontos in 3BSD setzte. Fünfzehn Wörter Absicht, noch immer von jedem Unix auf der Welt respektiert.

Aber ein * ist zu kurz, um ein Salt zu halten. Also leiht sich sshd eines: es nimmt das Salt von einem anderen lokalen Konto, das einen echten Hash hat, hasht deinen Versuch trotzdem und vergleicht. Diese Ausleihe kam im Juli 2016 als Fix für CVE-2016-6210, einen Timing-Oracle, der Angreifern erlaubte, gültige Benutzernamen aufzuzählen. Dieselbe Zeit auf einen nicht existierenden User zu verschwenden war der ganze Punkt.

Nun addiere 2012. musl, die C-Bibliothek, auf der Alpine gebaut ist, änderte crypt() so, dass ein fehlgeschlagener Aufruf ein einzelnes * statt NULL zurückgibt, weil zu viele Programme nie auf NULL prüften und einfach abstürzten. Zwanzig Tage später deckelte musl sha256- und sha512-Hashing bei 256 Bytes, um Denial-of-Service-Angriffe zu stoppen, die dem Hasher riesige Eingaben füttern.

Lege diese Entscheidungen in einen Prozess und die Logik kehrt sich um:

1. Das gespeicherte Feld ist *.
2. Dein Passwort ist 257 Bytes oder mehr, also lehnt crypt() es ab und gibt * zurück.
3. sshd vergleicht * mit *.
4. Es passt.

Der Fehlerpfad ist die Tür. Nicht ein Bug im Sinne eines verirrten Speicherschreibens, sondern eine Kette von vier einzeln vernünftigen Entscheidungen, getroffen über Jahrzehnte hinweg, die jetzt auf die falsche Antwort einigen.

Wer wirklich exponiert ist

Alpines Advisory listet vier Bedingungen, die alle zutreffen müssen:

• Der Server läuft openssh-server, das ohne PAM gebaut wird, oder läuft openssh-server-pam mit UsePAM no.
• PasswordAuthentication ist yes, was der OpenSSH-Standard ist.
• Ein Konto hat * in seinem Passwortfeld, was bedeutet, dass kein Passwort gesetzt ist.
• Mindestens ein anderes lokales Konto hat einen $5$- oder $6$-Hash.

Diese letzte Bedingung ist die leise. Ein einziges Konto irgendwo auf der Maschine mit einem modernen Passwort-Hash reicht, um jedes Konto ohne einen solchen offenzulegen. Auf Alpine umfassen Konten ohne Passwort schlüsselbasierte User, die mit adduser erstellt wurden, Verzeichnis-User, die über musl-nscd hereinkommen, und root, das seit Alpine 3.16 als root:* ausgeliefert wird.

Root ist weiterhin durch PermitRootLogin prohibit-password geschützt, sofern du es nicht geändert hast. Dieser Schild bedeutet weniger als es klingt, wenn ein exponiertes Konto eskalieren kann: die tiny-cloud-Images von 3.18.11 bis 3.24.3 geben dem alpine-User passwortloses doas. Diese Images sind beim ersten Boot sicher und öffnen sich, sobald irgendein $6$-Hash auf der Maschine existiert, was beim ersten Mal passiert, wenn ein Admin ein Konsolen-Passwort setzt.

Der Angreifer braucht Netzwerkzugang, einen Kontonamen und ein Passwort zwischen 257 und 1.024 Bytes. Das Advisory sagt, es gelingt bei jedem Versuch, über eine einzelne Verbindung. Als der Fix erschien, waren keine Angriffe bekannt, die ihn nutzten.

Nicht betroffen: Nicht-Linux-Systeme, glibc-basiertes Linux, alles, das Passwörter über PAM prüft, Systeme mit PasswordAuthentication no, mit ! statt * gesperrte Konten, Container, die kein sshd ausführen, und Maschinen, auf denen kein Konto einen $-stiligen Hash trägt. OpenWrt ist weitgehend in Ordnung, weil es standardmäßig Dropbear nutzt. Buildroot und Yocto verdienen einen Blick.

Was du heute tun solltest

Der Forscher, der es fand, Özgün Kültekin von Wakefield, veröffentlichte eine vollständige Analyse auf sshhole.com, und der Spitzname, der hängen blieb, ist in einem Kunden-Deck nicht druckbar. Die Behebung ist langweilig und schnell:

1. Update. Führe apk upgrade -U -a aus, dann rc-service sshd restart. Das Aktualisieren des Pakets startet den laufenden Daemon nicht neu, also ist der Neustart nicht optional. Feste Punkt-Releases: 3.21.10, 3.22.8, 3.23.8 und 3.24.4. Branches zurück bis 3.16 sind über das Supportende hinaus, bekamen aber trotzdem Pakete.
2. Wenn du nicht sofort patchen kannst, schalte Passwort-Logins ab. Bestätige, dass dein Schlüssel-Login in einer zweiten Sitzung funktioniert, bevor du die erste schließt. Setze PasswordAuthentication no, führe sshd -t aus, starte sshd neu. Verifiziere mit sshd -T | grep -i passwordauthentication.
3. Jagd. Durchsuche /var/log/messages nach Accepted password for gegen ein Konto ohne Passwort: alpine, root, ein nur-schlüsselbasierter Deploy-User. Prüfe doas-Nutzung, kürzlich erstellte User, geänderte autorisierte Keys und Dateiänderungen.
4. Wenn du einen Login nicht ausschließen kannst, behandle die Maschine als kompromittiert. Das Advisory ist so direkt, und es hat recht.

Wenn du OpenSSH selbst baust, enthält 10.6p2 die Änderung: sshd lehnt nun eine Übereinstimmung ab, wenn das gespeicherte Feld kürzer als vier Zeichen ist. OpenSSH nennt das einen Workaround und weist auf musl als Root-Ursache.

Warum der Fix in einem Tag kam

Als das Advisory herauskam, war noch keine CVE-ID vergeben. Damien Miller war ausdrücklich, warum sein Team mit dieser Geschwindigkeit handelte: lange Embargos sind jetzt gefährlich und helfen vor allem Angreifern, weil das Projekt kürzlich beobachtet hat, wie KI-Agenten dieselben Bugs wiederentdeckten, manchmal innerhalb von Stunden.

Lies diesen Satz zweimal, denn das ist die wahre Geschichte. Die Verwundbarkeit ist eine Designentscheidung von 2016, die mit einer Bibliotheksänderung von 2012 kollidiert. Die Reaktionszeit setzen Maschinen, die Code die ganze Nacht lesen und ein Finding aus einer teilweise öffentlichen Spur innerhalb eines Arbeitstags neu ableiten können. Embargo-Fenster wurden früher an menschlicher Aufmerksamkeit gemessen. Sie werden jetzt an Inferenz-Durchsatz gemessen.

Was das für dein Team bedeutet

Drei Dinge, und nur das erste ist über OpenSSH.

Auditiere das Basis-Image, nicht nur die Anwendung. Die meisten Teams, die wir treffen, können ihre Framework-Version nennen und nicht ihre libc. Alpines Allgegenwart in Containern bedeutet, dass musls Defaults deine Defaults sind, und musl traf 2012 eine vertretbare Entscheidung, die 2026 zu einem Authentifizierungs-Bypass wurde.

Schreib deine Annahmen auf, damit sie falsifizierbar werden. "Nur-schlüsselbasierte Konten können sich nicht mit einem Passwort einloggen" war wahr, weit verbreitet geglaubt und in hunderte interne Runbooks kopiert. Es hörte auf wahr zu sein, ohne dass jemand die Runbooks editierte.

Nimm an, dass dein leisestes Konto das ist, das zählt. Das Konto ohne Passwort, ohne Shell-History, ohne Owner im Organigramm. In diesem Fehler war es das Ziel, und ein einzelner stray $6$-Hash irgendwo auf der Maschine machte daraus die Haustür.

Patche, starte neu, verifiziere. Dann stelle die Frage, die wirklich bezahlt wird: welche unserer Annahmen wurde nicht neu getestet, seit die Maschinen schneller sind als wir?