Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Openssh auf musl basierte Distributionen dringend updaten
@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.
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.
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.