Ein Angreifer, der Ihren SSH-Port erreichen kann, kann sich ohne Kenntnis eines Passworts

„Ein Angreifer, der Ihren SSH-Port erreichen kann, kann sich ohne Kenntnis eines Passworts anmelden, warnten die Maintainer von Alpine Linux am Donnerstag vor einer Sicherheitslücke, die es ermöglicht, Passwörter bei bestimmten Linux-Systemen einfach zu umgehen.

Angreifer können durch die Eingabe eines ungewöhnlich langen Passworts Zugriff auf Konten erlangen, die eigentlich keine Passwort-Authentifizierung zulassen. Die Schwachstelle, die unter dem Namen „*sshole bekannt wurde, betrifft OpenSSH auf Systemen, die die C-Bibliothek musl verwenden und keine Pluggable Authentication Modules (PAM) nutzen.

So umgehen überlange Passwörter die Sicherheit

Der Fehler entspringt der Interaktion zwischen dem OpenSSH-Daemon (sshd) und der musl-Bibliothek. Wenn ein Benutzer ein Passwort eingibt, das länger als 256 Bytes ist, gibt die Funktion crypt() von musl ein Sternchen (*) zurück, um den Fehler zu signalisieren.

Da in der Linux-Datei /etc/shadow Passwollos-Konten oft durch ein Sternchen markiert sind, vergleicht OpenSSH das Fehlerzeichen der Bibliothek mit dem gespeicherten Zeichen des Kontos. Die Schwachstelle wird als CVE-2026-123158 geführt und erhielt eine CVSS 3.1-Bewertung von 8,1, was als „High“ eingestuft wird. Um die Sicherheitsbarriere zu durchbrechen, müssen Angreifer ein Passwort zwischen 257 und 1.024 Zeichen verwenden.

Die technische Ursache dieser Interaktion ist auf mehrere Entscheidungen über mehr als ein Jahrzehnt zurückzuführen. Der Forscher Özgün Kültekin von Wakefield weist darauf hin, dass die Wurzeln der Problematik bis in die BSD-Unix-Ära zurückreichen, als das Passwort-File des Daemon-Users ein einzelnes Sternchen enthielt.

Die spezifische musl-Problematik entstand durch Änderungen im Jahr 2012: Am 9. August 2012 wurde eine Änderung vorgenommen, die bei einem fehlgeschlagenen crypt()-Aufruf ein unpassendes Hash statt NULL zurückgab, da viele Programme den Fehler nicht prüften. Am 29. August 2012 folgte eine 256-Byte-Beschränkung, um Denial-of-Service-Risiken durch langsame SHA-512-Hashing-Prozesse zu mindern. Die Verbindung zu OpenSSH entstand 2016 durch eine Änderung zur Vermeidung von Username-Enumeration (CVE-2016-6210), bei der sshd auch für Konten ohne nutzbaren Passwort-Hash Dummy-Hashing-Operationen durchführte, um Antwortzeiten anzugleichen.

Alpine Linux und Cloud-Images sind besonders gefährdet

Besonders gefährdet ist das Betriebssystem Alpine Linux, das aufgrund seines geringen Speicherbedarfs häufig als Basis für Container und Cloud-Umgebungen dient. Laut The Hacker News sind auch OpenWrt, Buildroot, Yocto und Void Linux potenziell betroffen, sofern sie OpenSSH verwenden und musl nutzen. Bei OpenWrt ist das Risiko nur dort gegeben, wo Administratoren den Standard-SSH-Server Dropbear durch OpenSSH ersetzt haben.

Ein kritisches Szenario ergibt sich bei den offiziellen Cloud-Images von Alpine für AWS und Azure. Diese nutzen ein Standard-Konto namens „alpine“, das für den Zugriff ohne Passwort konfiguriert ist und über „doas-Rechte verfügt.”

Systeme, die die GNU C-Bibliothek (glibc) verwenden, wie etwa Debian, Ubuntu oder Fedora, sowie Systeme, die PAM zur Authentifizierung nutzen, sind von dieser spezifischen Schwachstelle nicht betroffen.

Eine erfolgreiche Ausnutzung setzt folgende Bedingungen voraus:

• OpenSSH wird ohne PAM-Unterstützung betrieben (oder mit UsePAM no).
• Die Passwort-Authentifizierung ist in der Konfiguration aktiviert (PasswordAuthentication yes).
• Das Zielkonto hat in der Datei /etc/shadow ein Sternchen (*) im Passwortfeld.
• Ein anderes lokales Konto auf demselben System besitzt einen Passwort-Hash, der mit $5$ oder $6$ beginnt.

OpenSSH veröffentlicht Notfall-Update

OpenSSH hat am 5. November 2026 die Version 10.6p2 als Notfall-Update veröffentlicht, um den Bypass zu verhindern. In dieser Version lehnt sshd Übereinstimmungen ab, wenn das gespeicherte Passwortfeld kürzer als vier Zeichen ist. Die OpenSSH-Entwickler betrachten dies als Workaround, da die eigentliche Ursache außerhalb von sshd liege.

Alpine hat bereits korrigierte Pakete für alle unterstützten Branches bereitgestellt, einschließlich der Versionen 3.21.10, 3.22.8, 3.23.8 und 3.24.4. Für ältere Zweige sind ebenfalls gepatchte Pakete verfügbar, die bis zurück zur Version 3.16 reichen.

Administratoren können die Passwort-Authentifizierung in der OpenSSH-Konfiguration explizit auf „no setzen und den Dienst neu starten, falls ein sofortiges Update der Software nicht möglich ist. Dies kann über eine Drop-in-Datei in /etc/ssh/sshd_config.d erfolgen, was in Alpine ab Version 3.19 standardmäßig unterstützt wird.

Fragen zur Sicherheit von Root-Accounts

Sind meine Root-Accounts direkt gefährdet?

Nach Angaben von IONIX schützt die Standardeinstellung PermitRootLogin prohibit-password den Root-Account vor direktem Zugriff per Passwort. Dennoch können Angreifer über Konten mit „doas– oder „sudo-Rechten Root-Privilegien erlangen.

Was muss ich tun, wenn ich kein Update installieren kann?

Falls ein sofortiges Update der Software nicht möglich ist, sollten Administratoren die Passwort-Authentifizierung in der OpenSSH-Konfiguration explizit auf „no setzen und den Dienst neu starten. Dies unterbindet den primären Angriffsweg über überlange Passwörter.

Die Entdeckung der Schwachstelle durch den Forscher Özgün Kültekin erfolgte unter Einsatz von KI-Agenten, die rund 17.600 Test-Anmeldungen mit verschiedenen Konfigurationen durchführten.