Für eine SSH-Anmeldung an manchen Alpine-Servern genügte bis Donnerstag ein beliebiges Passwort, solange es nur lang genug war, und ausgerechnet bei Konten, die gar kein Passwort haben. Die Lücke mit dem Spitznamen „*sshole“ steckt im Zusammenspiel von OpenSSH und der C-Bibliothek musl. Das OpenSSH-Projekt hat am 5. November die Version 10.6p2 mit einem „kritischen Sicherheits-Workaround“ veröffentlicht, Alpine Linux zeitgleich aktualisierte Pakete für alle Zweige ab 3.16. Die Schwachstelle hat die Kennung CVE-2026-123158 und im CVE-Eintrag einen CVSS-Wert von 8,1 („hoch“). Gemeldet hat sie Özgün Kültekin vom Unternehmen Wakefield.

Wie die Lücke funktioniert

Ohne PAM prüft sshd ein Passwort selbst: Es jagt die Eingabe durch die Bibliotheksfunktion crypt() und vergleicht das Ergebnis mit dem Eintrag in /etc/shadow. Steht dort nur ein Sternchen, lässt sich das Konto nach alter Unix-Konvention nicht per Passwort öffnen. So sind etwa reine Schlüsselkonten angelegt. Damit Angreifer an der Antwortzeit nicht ablesen können, welche Konten existieren oder ein Passwort haben, rechnet sshd bei solchen Einträgen trotzdem einen Hash aus. Weil ein Sternchen kein Salt enthält, leiht sich sshd dafür das Salt eines anderen Kontos mit echtem Passwort-Hash.

Genau hier greift das Verhalten von musl. Dessen crypt() liefert laut Alpine-Advisory bei Schlüsseln über 256 Byte als Fehlerkennung die Zeichenkette * zurück. Die Längengrenze für SHA-256- und SHA-512-Hashes hatte musl 2012 eingeführt, laut der Analyse des Entdeckers zum Schutz vor Denial-of-Service. Schickt ein Angreifer also ein Passwort mit 257 bis 1024 Byte für ein Konto mit Sternchen, ist das „Ergebnis“ * – und stimmt mit dem gespeicherten Eintrag überein. Die Anmeldung gelingt laut Alpine mit einer einzigen Verbindung und zuverlässig. Voraussetzung ist, dass auf dem System mindestens ein weiteres Konto einen Hash vom Typ $5$ oder $6$ besitzt. Konten mit gültigem eigenem Passwort lassen sich so nicht übernehmen.

Wo der Fehler liegt, ist umstritten. Das OpenSSH-Team schreibt, die eigentliche Ursache liege außerhalb von sshd, lasse sich dort aber abfangen. Der Fix lässt die Passwortprüfung nun grundsätzlich scheitern, wenn der gespeicherte Hash kürzer als vier Zeichen ist. musl-Maintainer Rich Felker sieht keinen Fehler in musl, sondern eine fehlerhafte Verwendung durch den Aufrufer. Den zugrunde liegenden Mechanismus wolle man aber sehr wahrscheinlich im kommenden Release-Zyklus ändern. Auf der Mailingliste oss-security entspann sich eine Debatte darüber, wie crypt() Fehler überhaupt melden soll: POSIX lässt das weitgehend offen, manche Implementierungen geben einen Nullzeiger zurück, andere eine Fehlerzeichenkette.

Wer betroffen ist

Betroffen sind Linux-Systeme mit musl, auf denen sshd ohne PAM läuft und Passwort-Logins erlaubt. Systeme mit glibc wie Debian, Ubuntu oder Fedora sind ebenso wenig betroffen wie Installationen mit PAM oder andere Betriebssysteme. Laut Alpine-Advisory musst du handeln, wenn alle folgenden Punkte zutreffen:

  • Du nutzt das Paket openssh-server, das ohne PAM gebaut ist, oder openssh-server-pam mit UsePAM no.
  • PasswordAuthentication steht auf yes, was der OpenSSH-Standard ist.
  • Mindestens ein Konto hat * im Passwortfeld, etwa Schlüsselkonten, die per adduser ohne Passwort angelegt wurden, Nutzer aus Verzeichnisdiensten oder root, das seit etwa Alpine 3.16 als root:* ausgeliefert wird.
  • Mindestens ein lokales Konto hat einen $5$- oder $6$-Hash.

Root selbst schützt die Standardeinstellung PermitRootLogin prohibit-password. Das hilft aber nicht, wenn ein anderes erreichbares Konto per doas zu root werden kann. Genau das betrifft die offiziellen Cloud-Images (tiny-cloud) von 3.18.11 bis 3.24.3: Ihr Nutzer alpine hat ein Sternchen im Passwortfeld und darf ohne Passwort doas nutzen. Beim ersten Start sind die Images sicher, angreifbar werden sie, sobald irgendein $6$-Hash auf der Maschine existiert, etwa weil ein Admin ein Konsolenpasswort gesetzt hat. Nicht betroffen sind Container ohne sshd, per cloud-init eingerichtete Images, die Passwort-Logins abschalten, und Konten mit ! im Passwortfeld. Auch der alternative SSH-Server Dropbear ist nicht anfällig. Dessen Maintainer hatte zunächst vor alten Versionen gewarnt, die Warnung nach einem Hinweis von Rich Felker aber zurückgenommen.

Symbolbild: SSH-Anmeldung an einem entfernten Server im Terminal

Bild: Symbolbild, SSH-Anmeldung im Terminal – Screenshot von Chenyijia001, Wikimedia Commons, Lizenz CC BY-SA 4.0

Was du jetzt tun solltest

Alpine rät, sofort zu aktualisieren und sshd danach neu zu starten. Das Paket-Update allein ersetzt den laufenden Daemon nicht. Die korrigierten Pakete stecken auch in den Point-Releases 3.21.10, 3.22.8, 3.23.8 und 3.24.4:

apk upgrade -U -a
rc-service sshd restart

# installierte Version prüfen
apk info -v | grep openssh

Diese openssh-Versionen enthalten den Fix: edge 10.6_p2-r0, 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, 3.20 9.7_p1-r6, 3.19 9.6_p1-r3, 3.18 9.3_p2-r4, 3.17 9.1_p1-r7 und 3.16 9.0_p1-r6. Für die Zweige bis 3.21, die keine reguläre Pflege mehr erhalten, hat Alpine ausnahmsweise ebenfalls Pakete gebaut. Beachte, dass die stabilen Zweige einen zurückportierten Patch tragen: Die OpenSSH-Versionsnummer bleibt dort älter als 10.6p2, maßgeblich ist die Paketrevision.

Kannst du nicht sofort aktualisieren, schalte Passwort-Logins ab. Prüfe vorher, dass deine Anmeldung per Schlüssel funktioniert, und halte die bestehende Sitzung offen, bis ein neuer Login klappt. Ab Alpine 3.19 liest die Standardkonfiguration ein Drop-in-Verzeichnis. Für ältere Versionen enthält das Advisory zusätzlich einen sed-Befehl, der die Hauptkonfiguration anpasst:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication   # soll "passwordauthentication no" ausgeben

Ob jemand die Lücke schon ausgenutzt hat, verraten die Logs. Suche in /var/log/messages nach Zeilen mit „Accepted password“ für Konten ohne Passwort, also etwa alpine, root oder Schlüsselkonten. Welche Konten ein Sternchen tragen, zeigt dir ein Blick in die Shadow-Datei. Prüfe außerdem die doas-Nutzung, neu angelegte Nutzer, Dateien und authorized_keys. Lässt sich ein unbefugter Login nicht ausschließen, solltest du die Maschine laut Alpine als kompromittiert behandeln.

grep "Accepted password" /var/log/messages
awk -F: '$2 == "*" { print $1 }' /etc/shadow

Einordnung: alter Fehler, schneller Fix

Der Fehler existiert laut dem Entdecker seit 2016, als OpenSSH den Salt-Trick gegen eine damalige Lücke zur Erkennung gültiger Benutzernamen (CVE-2016-6210) einführte. Gefunden hat Kültekin ihn, indem er sshd in vielen Varianten baute, mit und ohne musl, PAM und Shadow-Datei, und nach eigenen Angaben rund 17.600 ungewöhnliche Logins mit Schwärmen von KI-Agenten dagegen laufen ließ. OpenSSH-Entwickler Damien Miller schrieb, das Team habe erst am Vortag von dem Problem erfahren und das Release so schnell wie möglich herausgebracht. Man habe zuletzt mehrfach erlebt, dass KI-Agenten Fehler mitunter binnen Stunden wiederentdecken, und halte lange Embargos daher inzwischen für gefährlich, weil sie vor allem Angreifern nützten.

Eile ist auch deshalb geboten, weil das Ausnutzen trivial ist und auf GitHub bereits Testumgebungen zum Nachstellen kursieren, auf die der CVE-Eintrag verweist. Die US-Behörde CISA hat in ihrer Bewertung vermerkt, dass ein Proof of Concept existiert, und stuft die technischen Auswirkungen als „total“ ein. Ob weitere Programme unter musl auf ähnliche Weise anfällig sind, ist bislang offen; für Dropbear hat der Maintainer Entwarnung gegeben.

Quellen

Bildnachweis