Seit Jahrzehnten bekommen wir alle dieselbe Predigt zu hören: Kurze Passwörter sind ein Sicherheitsproblem. Nehmt lieber eine lange Passphrase, gern mit Sonderzeichen, gern aus dem Passwortmanager. Seit heute ist klar: Lange Passwörter sind auch ein Problem. Zumindest dann, wenn sie länger als 256 Byte sind und auf einen OpenSSH-Server treffen, der ohne PAM auf musl libc läuft. Dann ist nämlich jedes Passwort das richtige.
Ein Sternchen ist ein Sternchen
Die Lücke hört auf den schönen Namen *sshole und wurde von Özgün Kültekin (Wakefield) gefunden. Unter den passenden Voraussetzungen meldet sich ein Angreifer per SSH mit einem beliebigen Passwort zwischen 257 und 1024 Byte an. Und zwar ausgerechnet bei Accounts, die eigentlich gesperrt sind und gar kein Passwort haben sollen. Darunter kann sich auch root befinden.
Die Ursache ist fast schon komisch. Gesperrte Accounts tragen in der /etc/shadow statt eines Passwort-Hashes oft nur ein *. Die crypt()-Funktion von musl liefert ebenfalls ein * zurück, wenn bei der Passwortverarbeitung etwas schiefgeht. Und genau das passiert bei Passwörtern über 256 Byte. OpenSSH vergleicht dann Sternchen mit Sternchen, findet beide gleich und winkt den Besucher brav durch.
Entstanden ist das Ganze nicht durch einen einzelnen Patzer, sondern durch mehrere für sich genommen harmlose Änderungen. musl hat 2012 sowohl den Rückgabewert im Fehlerfall als auch die Längengrenze eingeführt. OpenSSH hat 2016 eine Timing-Lücke gestopft und damit dafür gesorgt, dass der Fehler auch echte Benutzer mit * erreicht. Rund zehn Jahre ist das niemandem aufgefallen.
Entwarnung für den Linux-Desktop
Wer auf seinem Arch-Rechner, seinem Ubuntu-Notebook oder seinem Heimserverchen mit Debian einen sshd laufen hat, kann sich entspannt zurücklehnen. Die großen Distributionen setzen auf glibc statt musl und lassen OpenSSH in der Standardkonfiguration über PAM prüfen. Damit ist der Weg zum Sternchen-Vergleich gar nicht erst offen. Laut Analyse sind Debian, Ubuntu und Fedora nicht betroffen, ebenso wenig OpenBSD und Dropbear.
Betroffen sind nur Systeme, bei denen alle diese Punkte zusammenkommen:
- Linux mit musl libc (etwa Alpine Linux, OpenWrt, Buildroot oder Yocto)
- OpenSSH ohne PAM
- Passwortauthentifizierung aktiviert
- mindestens ein Account mit
*als Passwortfeld in/etc/shadow - mindestens ein weiterer Account mit gültigem Passwort-Hash
Gruselig wird es dort, wo keiner hinschaut
Auf dem Papier klingt die Liste nach einer Nische. Bei Alpine Linux ist sie allerdings Standard: Das Paket openssh-server arbeitet dort ohne PAM, Passwort-Logins sind an, und root hat seit Alpine 3.16 ein * als Hash. Auf den offiziellen Images für AWS und Azure gibt es zudem den Benutzer alpine, der per doas ohne Passwort zu root wird. Ein langes Passwort, ein doas, fertig.
OpenWrt selbst kommt zwar mit Dropbear als SSH-Server, der nicht betroffen ist. Wer seinen Router aber auf OpenSSH umgestellt hat, etwa wegen SFTP, sollte genauer hinschauen. Richtig unangenehm wird es bei Buildroot und Yocto. Damit bauen Hersteller die Firmware für Router, NAS, Kameras, Industriesteuerungen und allerlei IoT-Kram. Was da genau drinsteckt, verraten die wenigsten Datenblätter.
Und genau diese Kisten hängen gerne direkt im Netz. Es sind die Geräte, die man einmal aufstellt und dann nie wieder anfasst, weil sie ja laufen. Updates gibt es, wenn überhaupt, nur dann, wenn der Hersteller sich daran erinnert, dass er das Ding mal verkauft hat. In meinen Augen ist das der eigentliche Gruselfaktor dieser Lücke, nicht der Linux-Desktop.
Was ihr jetzt tun solltet
OpenSSH hat heute Version 10.6p2 veröffentlicht, die das Problem auf der OpenSSH-Seite abfängt. Unter Alpine Linux zieht ihr das Update ganz normal über die Paketverwaltung mit apk upgrade openssh. Andere Distributionen beheben den Fehler per zurückportiertem Sicherheitspatch. Startet den SSH-Dienst danach neu, damit auch wirklich die neue Version lauscht. Bei Firmware von der Stange bleibt euch nur, beim Hersteller nach einem Update zu suchen.
Wer nicht sofort aktualisieren kann, schaltet die Passwortanmeldung in der sshd_config ab:
PasswordAuthentication noVorher solltet ihr natürlich sicherstellen, dass der Zugang per Schlüssel funktioniert, sonst sperrt ihr euch selbst aus. Unter Alpine geht das auch als eigene Konfigurationsdatei mit anschließendem Neustart des Dienstes:
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf
rc-service sshd restartGanz ehrlich: Ein SSH-Server mit Passwortanmeldung, der offen im Internet hängt, war auch vor *sshole keine gute Idee. Zu kurze Passwörter werden erraten, zu lange sind ab heute auch verdächtig. Das beste Passwort für SSH ist und bleibt keins, sondern ein Schlüssel. Habt ihr Alpine-Kisten oder einen OpenWrt-Router mit OpenSSH im Einsatz, und wisst ihr, was eure Geräte im Netz eigentlich für einen SSH-Server fahren?
Schreibe einen Kommentar