Alpine Linux behebt OpenSSH-Schwachstelle, bei der ein einziges Zeichen dein ganzes Wochenende ruinieren konnte

Das perfekte Albtraumszenario für einen Linux-Server ist, wenn ein Angreifer nur den SSH-Port (Secure Shell) des Servers erreichen muss, um einfach hineinzuspazieren und ihn zu übernehmen. Genau das ist bei Alpine Linux passiert, der beliebten schlanken Linux-Server-Distribution. Um die Sache noch schlimmer zu machen, geschah dies nur wenige Tage, nachdem Alpine Linux einer sicherheitslückenhaften Kugel in seiner GitLab-Implementierung ausgewichen war.

Wie der Sicherheitsingenieur Gregory Bryant in seinem LinkedIn-Beitrag erklärte: „Die meisten Authentifizierungsumgehungen entstehen durch komplexe Logikketten, aber die gestrige Alpine Linux OpenSSH-Schwachstelle (CVE-2026-123158) läuft auf ein einziges Zeichen hinaus: *.“

Wenn Sie Alpine Linux (oder eine andere musl-basierte Distribution) mit dem Standardpaket openssh-server (ohne Pluggable Authentication Modules, kurz PAM) und aktivierter PasswordAuthentication betreiben, kann ein Angreifer sich bei Konten mit deaktiviertem Passwort oder reinen Schlüssel-Konten einfach anmelden, indem er ein Passwort mit einer Länge zwischen 257 und 1024 Bytes sendet.

Alpine Linux ist nicht das einzige Betriebssystem, das musl verwendet, eine leichtgewichtige Version der Standard-C-Bibliothek (libc). Andere Betriebssysteme, die musl nutzen und potenziell anfällig sind, sind unter anderem Adélie Linux, Void Linux, Sabotage Linux, OpenWrt (eine Android-Variante) und das Yocto Project, das zum Bau eingebetteter Linux-Distributionen verwendet wird.

Wind River, Hersteller der kommerziellen eingebetteten Linux-Distribution Wind River Linux, untersucht das Problem ebenfalls. Ein Unternehmensvertreter sagte mir: „Wind River nimmt Sicherheit ernst. Wir prüfen die gemeldete Schwachstelle aktiv und bewerten ihre potenziellen Auswirkungen. Wir werden bei Bedarf geeignete Maßnahmen ergreifen.“

Hinter den Kulissen, wenn OpenSSH ohne PAM gebaut wird, überprüft es Passwörter, indem es den Passwortversuch mit der crypt()-Funktion der C-Bibliothek hasht. Anschließend vergleicht es das Ergebnis mit dem gespeicherten Passwortfeld des Kontos. So weit, so gut.

Doch wenn ein Schlüssel länger als 256 Bytes ist, gibt musls crypt()-Funktion den String * als Fehlerindikator zurück. Das ist auch der Inhalt des Passwortfelds für jedes Konto ohne Passwort, wie etwa reine Schlüssel-Konten. Somit stimmt der „Hash“ überein und die Anmeldung gelingt, und der Angreifer spaziert hinein.

Um dies auszunutzen, benötigt ein Angreifer lediglich den Namen eines solchen Kontos. Außerdem braucht er mindestens ein weiteres Konto auf dem Rechner mit einem 5- oder 6-Passwort-Hash und muss dann ein Passwort mit 257 bis 1.024 Bytes senden. Laut Alpine reicht ein Benutzer mit Passwort aus, um alle passwortlosen Konten zugänglich zu machen.

In Linux-Systemen, die glibc's crypt() verwenden – also fast alle –, würde derselbe Versuch bei einem Fehler NULL zurückgeben, was sshd bereits ablehnt. Daher sind Debian, Ubuntu, Fedora usw. nicht betroffen.

Laut *sshole, der Gruppe, die das Problem aufdeckte, handelt es sich um einen Nebeneffekt, der sich seit 2016 versteckt hat.

Alpine gab an, dass jede überprüfte Version betroffen ist: 3.21 bis 3.24, edge und die älteren Zweige 3.16 bis 3.20. Die Ausnutzbarkeit erfordert Folgendes:

Root ist in den meisten Fällen nicht direkt exponiert. Seit etwa Alpine 3.16 wird es als root:* im Basisimage ausgeliefert, aber OpenSSHs Standardeinstellung PermitRootLogin prohibit-password blockiert dies. Ein weiteres Konto, das zu Root werden kann, beispielsweise über doas, bietet einem Angreifer jedoch weiterhin einen Weg zu Root.

Alpine hob seine offiziellen tiny-cloud-Images, Versionen 3.18.11 bis 3.24.3, als besonders anfällig hervor. Diese werden mit einem Benutzer alpine mit einem *-Passwortfeld und passwortlosem doas ausgeliefert. Sie sind beim ersten Start sicher, werden jedoch ausnutzbar, sobald irgendein 6-Hash auf dem Rechner existiert. Das kann passieren, wenn ein Administrator ein Konsolenpasswort setzt oder wenn Benutzerdaten einen Benutzer mit einem gehashten Passwort hinzufügen – was im Wesentlichen auf alle zutrifft.

Alpine veröffentlichte am Donnerstag die Versionen 3.21.10, 3.22.8, 3.23.8 und 3.24.4, wobei der OpenSSH-Fix zu den Sicherheitsänderungen gehört. Es wurden auch korrigierte Pakete für jede Version bis zurück zu 3.16 veröffentlicht. Alpine 3.21 erreichte am 1. November das Ende der Unterstützung.

Das gerade veröffentlichte OpenSSH 10.6p2 vermeidet das Problem in sshd. Alpines stabile Zweige enthalten einen Patch für dasselbe Problem. Sie sollten apk upgrade -U -a ausführen und dann sshd neu starten.