Openssh auf musl basierte Distributionen dringend updaten

Das betrifft aber, soweit ich sehe, nur Systeme, die am Internet hängen und SSH mit Passwort erlauben. Sowas macht hoffentlich sowieso niemand.

Normal konfigurierte Systeme (SSH nur mit Zertifikat) sind hier also erst mal nicht in Gefahr.
 
Jo. Ist ssh mit Passwort. Zb bei openwrt dürfte das der Default sein, bei diversen Containern auch.
 
@CoMo
Da steht auch "yocto" und "buildroot", d.h. es können alle möglichen embedded Linux-System betroffen sein. Kann man sich freuen, wenn diese nun leicht zu rooten sind, aber das kann auch erhebliche Sicherheitslücken in lokalen Netzwerken darstellen (IP-Kameras, Industrie-PCs, etc. etc.). Also nicht unbedingt daheim, aber in Firmen- oder Uninetzwerken, öffentlichen WLANs etc. V.a. dürften die wenigsten davon gepatched werden also die Lücke ewig offen bleiben.
 
Und die Lücke geht eigentlich auf Entscheidungen in der musl libc zurück.
  • Wenn ein Nutzer kein Passwort hat bzw. sich nicht per Passwort anmelden darf, dann ist sein Passwort-Hash * (was niemals ein gültiger Hash sein kann).
  • libc hat eine (schlecht benannte) Funktion crypt() die ein Passwort hashed. Um DoS-Angriffe zu verhindern gibt es eine Limitierung der Länge auf 256 Zeichen. Ist das Passwort länger verweigert die Funktion den Dienst und signalisiert dass das hashen nicht geklappt in dem sie * zurückgibt. Früher hat sie mal NULL returned... Man hat das geändert damit Programme die nicht auf NULL prüfen nicht mehr crashen...
Bei einem naiv implementierten Vergleich gibt es somit immer eine Übereinstimmung mit dem gespeicherten Hash, wenn man einfach ein Passwort länger als 256 Zeichen eingibt.

Angreifbar ist aber nur wenn ALLES zutrifft:
  • musl libc
  • OpenSSH
  • kein PAM (rauskompiliert oder UsePAM no)
  • Anmeldung per Passwort erlaubt (kein PasswordAuthentication no)
Anmerkung bzgl. OpenWRT: Standardmäßig ist da dropbear als ssh-Daemon installiert, welcher nicht von der Lücke betroffen ist. Man müsste das openssh Paket selbst installiert/ausgewählt haben um betroffen zu sein.

Ernsthaft betroffen dürfte in erster Linie Alpine sein. Container in der Regel jedoch nicht, da man darin fast nie einen SSH-Daemon betreiben wollen würde.
 
  • Gefällt mir
Reaktionen: rollmoped, andy_m4, Tornhoof und eine weitere Person
Marco01_809 schrieb:
Container in der Regel jedoch nicht, da man darin fast nie einen SSH-Daemon betreiben wollen würde.

Z.B. ein gitlab-Container schon (aber zumindest das gitlab-CE-Docker-Image verwendet glibc; nochmal davongekommen). Bei einem CI-Container kann ich's mir auch vorstellen.
 
  • Gefällt mir
Reaktionen: Marco01_809
Bei uns hatte zumindest eins der Container Image Scan Tools (mend io) angeschlagen, beides nodejs. Aber du hast wahrscheinlich Recht dass da kein ssh Server drauf läuft. Nicht geprüft, bei unseren mitigationsregeln aber auch egal.
 
Zurück
Oben