Kritische OpenSSH-Schwachstelle auf Alpine Linux ermöglicht Login mit langen Passwörtern

Eine kritische Schwachstelle in OpenSSH ermöglicht es Angreifern, die Authentifizierung bei bestimmten Alpine-Linux-Konfigurationen zu umgehen, indem sie übermäßig lange Passwörter eingeben. Das OpenSSH-Projekt hat am 5. November 2026 die Version 10.6p2 veröffentlicht, um das Problem zu beheben, während Alpine Linux Korrekturen für alle unterstützten Releases nachträglich integriert (Backporting) hat.

Was passiert ist

Angreifer mit Netzwerkzugriff können sich in Benutzerkonten einloggen, für die kein Passwort gesetzt ist, wie z. B. SSH-Key-only-Nutzer oder den Standard-alpine-Benutzer in Cloud-Images. Um erfolgreich zu sein, muss der Angreifer den Kontonamen kennen und ein Passwort zwischen 257 und 1.024 Bytes Länge angeben. Dieser Fehler betrifft speziell Systeme, auf denen das Standardpaket openssh-server unter Alpine Linux läuft, welches ohne die Schnittstelle für Pluggable Authentication Modules (PAM) erstellt wurde.

Die Schwachstelle entsteht durch eine Wechselwirkung zwischen der Logik zur Passwortprüfung von OpenSSH und musl, der C-Bibliothek, die von Alpine verwendet wird. Wenn die Passwortauthentifizierung aktiviert ist und mindestens ein anderes lokales Konto einen Passwort-Hash besitzt, akzeptiert der Server fälschlicherweise das lange Passwort für jedes Konto mit einem leeren Passwortfeld. Obwohl keine aktiven Exploits gemeldet wurden, stufte das OpenSSH-Team die Schwachstelle als kritisch ein und drängte auf sofortige Gegenmaßnahmen.

Damien Miller vom OpenSSH-Projekt betonte die Dringlichkeit und erklärte, dass Administratoren „sofort PasswordAuthentication=no setzen oder SSH für diese Systeme deaktivieren sollten.“ Der Fix wurde schnell veröffentlicht; Miller wies darauf hin, dass lange Embargos zunehmend gefährlich sind, da KI-Agenten solche Bugs innerhalb von Stunden wiederentdecken können.

Wie es funktioniert

Die Ursache liegt darin, wie sshd die Passwortüberprüfung handhabt, wenn PAM nicht verwendet wird. Normalerweise hasht sshd das eingegebene Passwort mit der Funktion crypt() und vergleicht es mit dem gespeicherten Hash in /etc/shadow. Konten ohne Passwort haben in diesem Feld das Zeichen *. Da * zu kurz ist, um einen Salt zu enthalten, entleiht sshd den Salt von einem anderen Konto, das einen Passwort-Hash besitzt.

Wenn ein Angreifer ein Passwort länger als 256 Bytes eingibt, verweigert die crypt()-Funktion von musl die Verarbeitung und gibt * zurück, um einen Fehler anzuzeigen. Da das gespeicherte Feld des Zielkontos ebenfalls * ist, schlägt der Vergleich fehl? Nein, er ist erfolgreich, und der Server gewährt Zugang. Dieses Verhalten resultiert aus einer Änderung in musl aus dem Jahr 2012, die Abstürze in Programmen verhindern sollte, die crypt()-Fehler nicht prüften, kombiniert mit einer OpenSSH-Änderung aus dem Jahr 2016, die verhindert werden sollte, dass Benutzernamen enumerierbar sind.

Die neue Version 10.6p2 führt eine Workaround-Maßnahme ein, die jede Übereinstimmung ablehnt, wenn das gespeicherte Passwortfeld kürzer als vier Zeichen ist. Während dies den Angriff stoppt, weist das OpenSSH-Team darauf hin, dass das zugrunde liegende Problem in der Handhabung langer Eingaben durch die C-Bibliothek liegt und nicht in SSH selbst.

Wichtige Details

• Betroffene Systeme: Alpine Linux, auf dem openssh-server ohne PAM läuft, oder openssh-server-pam mit UsePAM no.
• Voraussetzungen: PasswordAuthentication muss auf yes stehen, mindestens ein Konto muss einen $5$- oder $6$-Hash besitzen, und das Zielkonto muss * im Passwortfeld haben.
• Angriffsvektor: Ein einzelner Verbindungsversuch mit einem Passwort zwischen 257 und 1.024 Bytes ist jedes Mal erfolgreich.
• Risikoreiche Ziele: Der alpine-Benutzer in Tiny-Cloud-Images (Versionen 3.18.11 bis 3.24.3) ist verwundbar, sobald irgendein Passwort-Hash auf dem System existiert, was potenziell Root-Zugriff über doas ermöglicht.
• Nicht betroffene Systeme: Linux-Distributionen, die glibc verwenden, Systeme, die PAM für die Authentifizierung nutzen, und OpenWrt-Geräte, die Dropbear verwenden.
• Verfügbarkeit des Fixes: OpenSSH 10.6p2 ist jetzt verfügbar; Alpine hat aktualisierte Pakete für die Versionen 3.16 bis 3.24 bereitgestellt.

Warum das wichtig ist

Für Ingenieure, die Infrastruktur auf Alpine Linux aufbauen, untergräbt diese Schwachstelle die Sicherheit von Key-only-Authentifizierungssetups. Viele Entwickler verlassen sich auf Alpine wegen seiner geringen Größe in Containern und Cloud-Instanzen und gehen oft davon aus, dass das Deaktivieren von Passwort-Logins oder die Verwendung von SSH-Keys ausreichenden Schutz bietet. Da PasswordAuthentication jedoch in vielen Konfigurationen standardmäßig aktiviert ist, bleiben diese Systeme exponiert, bis sie explizit gehärtet werden.

Der Vorfall verdeutlicht auch den wachsenden Druck auf Open-Source-Maintainer, Patches schnell zu veröffentlichen. Die Entscheidung, ein traditionelles Embargo zu überspringen, spiegelt eine sich wandelnde Bedrohungslandschaft wider, in der automatisierte Tools Schwachstellen rasch rückentwickeln können. Teams müssen nun schnelle Patch-Zyklen priorisieren und davon ausgehen, dass technische Details kritischer Fehler fast unmittelbar nach ihrer Entdeckung öffentlich bekannt werden könnten.

Was Sie tun können

• Aktualisieren Sie Ihre Alpine-Pakete sofort mit apk upgrade -U -a und starten Sie den SSH-Dienst mit rc-service sshd restart neu.
• Wenn Sie nicht sofort aktualisieren können, deaktivieren Sie die Passwortauthentifizierung, indem Sie PasswordAuthentication no in Ihrer SSH-Konfiguration festlegen.
• Überprüfen Sie Ihre Konfigurationsänderungen, indem Sie sshd -T | grep -i passwordauthentication ausführen, um sicherzustellen, dass no zurückgegeben wird.
• Prüfen Sie /var/log/messages auf Einträge, die Accepted password for für Benutzer wie root oder alpine anzeigen, die keinen Passwortzugriff haben sollten.
• Überprüfen Sie die Nutzung von doas und kürzlich erstellte Benutzer auf potenziell exponierten Maschinen und betrachten Sie diese als kompromittiert, wenn verdächtige Aktivitäten festgestellt werden.
• Auditieren Sie andere musl-basierte Systeme wie Buildroot oder Yocto, falls sie OpenSSH ausführen, obwohl OpenWrt in der Regel sicher ist, wenn Dropbear verwendet wird.