SSHole — eine Schwachstelle, die eine Passwortlose SSH-Verbindung in Musl-Systemen ermöglicht

Die OpenSSH-Entwickler haben ein dringendes Update für OpenSSH 10.6p2 veröffentlicht, das einen Schutz gegen eine kritische Schwachstelle (CVE nicht vergeben), die den Code-Namen „SSHole“ trägt und eine Umgehung der Authentifizierung ermöglicht. In Systemen mit der Musl-Bibliothek erlaubt die Schwachstelle den Zugriff auf Benutzer, für die kein Passwort festgelegt ist, indem ein beliebiges Passwort eingegeben wird, das mehr als 256 Zeichen enthält. Das Problem betrifft Linux-Distributionen, die die Standardbibliothek musl verwenden, jedoch kein PAM (Pluggable Authentication Modules) implementieren, wie OpenWRT, Alpine, Buildroot und Yocto. Besonders bedenklich ist, dass der Passwortzugang häufig für den Benutzer root blockiert ist, was es jedem ermöglicht, sich mit Administratorrechten remote anzumelden.

Der Fehler, der zur Schwachstelle führt, liegt nicht im OpenSSH-Code, sondern wird über sshd ausgenutzt. Aufgrund der Schwere des Problems wird in der Version OpenSSH 10.6p2 eine Umgehungslösung empfohlen, um die Schwachstelle zu blockieren. Betroffenen Systembesitzern wird geraten, nicht auf Updates zu warten, sondern sofort die Passwortauthentifizierung durch den Parameter „PasswordAuthentication no“ in /etc/ssh/sshd_config zu deaktivieren oder SSH vollständig abzuschalten.

Das Problem tritt nicht in Systemen auf, die von Linux abweichen, und in Linux-Umgebungen, die auf glibc basieren, sowie in Systemen, die PAM für die Passwortauthentifizierung verwenden. Ein Fix ist bereits in Alpine und OpenWRT verfügbar.

Die Schwachstelle hängt mit der fehlerhaften Interaktion von OpenSSH und der Funktion crypt() aus musl zusammen. Zum Schutz der Benutzer vor der Bestimmung der Existenz von Benutzern durch die Analyse von Zeitunterschieden bei der Verarbeitung von Anfragen verwendet OpenSSH seit 2016 bei der Überprüfung passwortfreier Konten das Standardverfahren zur Passwortüberprüfung: Es ruft die Funktion „crypt(übergebenes Passwort, Salt)“ mit dem Salt eines anderen Benutzers auf, der einen gültigen Passwort-Hash hat, und vergleicht anschließend den von der Funktion crypt zurückgegebenen Hash mit dem Wert aus dem Feld mit dem Passwort-Hash.

In musl gibt die Funktion crypt() für SHA-512-Hashes jedoch das Zeichen „*“ zurück, wenn die Länge des übergebenen Passworts 256 Bytes überschreitet (diese Einschränkung wurde 2012 eingeführt, um DoS-Attacken zu verhindern, da beim Übertragen großer Werte eine hohe CPU-Belastung entsteht). Dasselbe Zeichen wird im Passwort-Hash-Feld in „/etc/shadow“ verwendet, um Konten zu kennzeichnen, bei denen die Passwortauthentifizierung blockiert ist.

Infolge eines Angriffs kann sich ein Angreifer, der sich mit dem SSH-Server verbinden kann, mit jedem Konto verbinden, dessen Passwortfeld im „/etc/shadow“ das Zeichen „*“ enthält, indem er einen String mit einer Länge von 257 bis 1024 Bytes überträgt. Das Problem betrifft viele vorhandene Docker-Images, die auf Alpine Linux basieren, sowie die Standard-Alpine-Images für Cloud-Systeme wie AWS und Azure, bei denen für den Benutzer root anstelle des Passwort-Hashes das Zeichen „*“ gesetzt wurde.

Bemerkenswert ist, dass in den offiziellen Docker-Images, die Alpine verwenden, seit 2015 zunächst kein Passwort für root festgelegt wurde. Nach Entdeckung dieses Faktors wurde das Zeichen „!“ anstelle des Passwort-Hashes gesetzt. Doch dessen Vorhandensein blockierte den Zugang über SSH-Keys, sodass seit 2022 das Zeichen zum Blockieren des Zugangs über das Passwort durch „*“ ersetzt wurde.

Quelle: opennet.ru