LONDON (IT BOLTWISE) – Eine seit 2016 bekannte OpenSSH-Sicherheitslücke lässt sich auf bestimmten musl-basierten Linux-Systemen missbrauchen, indem ein Angreifer ein extrem langes Passwort eingibt. Unter engen Voraussetzungen kann dadurch ausgerechnet auch ein Root-Login bzw. der Zugriff auf gesperrte Konten möglich werden. Der entscheidende Fix ist in OpenSSH-Versionen ab 10.6p2 enthalten, alternativ hilft das Deaktivieren der Passwortauthentifizierung. Besonders relevant sind Systeme wie Alpine Linux in Cloud-Images, bei denen musl als Standard-C-Library genutzt wird.
Auf den ersten Blick wirkt „sshole“ wie eine typische Nischen-Sicherheitsmeldung: Sie betrifft nicht jede Linux-Distribution, sondern nur Konfigurationen, in denen OpenSSH auf einer bestimmten C-Library aufsetzt. Entscheidend ist hier die musl libc statt der weit verbreiteten GNU C Library. Wird OpenSSH in genau diesem Umfeld so betrieben, dass Passwortauthentifizierung aktiv ist und PAM fehlt, kann ein Angreifer über das reine „Eingeben eines Passworts“ weiterkommen, als es die Logik der Kontenbasis zulässt.
Technisch knüpft die Schwachstelle an die Art an, wie OpenSSH Passwörter prüft. Musl begrenzt Passwörter auf 256 Bytes, während Angriffe mit deutlich längeren Eingaben zwischen 257 und 1.024 Zeichen die Interaktion zwischen Hashing-Code und Rückgabewerten ausnutzen können. Der Kern liegt darin, dass das Hashing-System bei bestimmten Fehlerzuständen ein Sonderverhalten zeigt: Für Konten, deren Passwortfeld mit einem Stern (*) markiert ist (also typischerweise „kein Passwort-Login vorgesehen“), statt eines Hashs aber trotzdem eine Verarbeitung angestoßen wird, kann die Überprüfung im Zusammenspiel mit der musl-Implementierung aus dem Ruder laufen. Damit rücken Konten in den Fokus, die eigentlich keine Passwörter akzeptieren sollten – etwa Root, reine Key-only Deployment-Accounts oder bestimmte LDAP-nutzende Benutzer.
Wichtig ist dabei: Der Angriff funktioniert nicht „einfach so“ für beliebige Nutzer. Die Zielkonten müssen ein Passwortfeld mit einem Stern (*) besitzen, während gleichzeitig mindestens ein anderer Account existieren muss, dessen Passwort tatsächlich als Hash vorliegt. Außerdem bleibt das direkte Root-Login an die OpenSSH-Konfiguration gebunden; die Lücke ermöglicht also nicht automatisch jedes Szenario, sondern schafft eine Möglichkeit, die bestehenden Authentifizierungsgrenzen unter den genannten Randbedingungen zu umgehen. Der Zeitraum für den potenziellen Missbrauch ist damit weniger ein „Flächenschaden“ als ein präzises Zusammenspiel von Plattform, Bibliothek und SSH-Setup.
Der Blick auf die historische Entwicklung macht das Muster greifbar. Der Text zur Schwachstelle ordnet die Wurzel des Problems bis in die BSD-Unix-Zeit zurück, als im Passwortdatensatz für einen Daemon-Account ein einzelner Stern im relevanten Feld stand und Passwortauthentifizierung faktisch blockiert wurde. Moderne Systeme trennen heute üblicherweise zwischen Klartext-Eingabe, Hashspeicherung (typisch in /etc/shadow) und der Vergleichslogik über crypt(). Problematisch wird es dann, wenn kryptografische Hilfsroutinen Fehler liefern und das aufrufende Programm die Fehlerpfade nicht robust genug behandelt. In der beschriebenen musl-Variante entscheiden die Autoren über ein bestimmtes Rückgabeverhalten, das in Kombination mit dem OpenSSH-Authentifizierungsfluss zu einem ungewollten „Sonderfall“ führt.
Daneben spielt auch die Performance-Ebene eine Rolle. Musl nutzt zeitweise SHA-512-basierte Passwort-Hashing-Varianten, die sich mit der Länge des Passworts spürbar verlangsamen können. Genau das kann man missbrauchen, um über extrem lange Eingaben nicht nur die eigentliche Logik zu beeinflussen, sondern auch eine Denial-of-Service-Situation zu verschärfen – die Grenzen (256 Bytes) wirken dabei wie eine Schutzkante. Dass diese Schutzkante in Verbindung mit den Stern-Markierungen und dem OpenSSH-Workaround für Timing-Informationen nicht in allen Fällen sauber „zu Ende“ gedacht wurde, ist die eigentliche Story hinter „sshole“.
OpenSSH hat den Fehler inzwischen behoben, und zwar laut den Angaben in der Meldung in Builds ab 10.6p2 (veröffentlicht am Donnerstag). Für Betreiber bedeutet das vor allem: Version prüfen, Upgrade einplanen und anschließend den geänderten Authentifizierungsverlauf gegen die eigenen Audit-Anforderungen testen. Wer nicht sofort updaten kann, hat als zweite, pragmatische Maßnahme einen sehr direkten Hebel: Passwortauthentifizierung deaktivieren und den SSH-Dienst neu starten. Damit entfernt man die gesamte Angriffsfläche, die an die Verarbeitung eines eingegebenen Passworts gekoppelt ist.
Für die Priorisierung ist die Frage nach der Plattform entscheidend. Musl ist in Embedded-Linux-Systemen verbreitet, weil die Laufzeitbibliothek relativ schlank ausfällt. Noch stärker wächst die Relevanz aber über Alpine Linux: Dort ist musl die Standard-C-Library, und aus diesem Ökosystem kommen auch offizielle Cloud-Images. Wenn diese Images in Umgebungen mit aktivem Passwort-Login und ohne PAM landen, steigt die Wahrscheinlichkeit, dass die Voraussetzungen erfüllt sind. Zwar gibt es laut Quelle keine Hinweise auf bereits erfolgte Ausnutzung, aber gerade bei SSH ist „keine Meldung“ kein Ersatz für schnelle Hygiene.
Wenn Teams nachziehen wollen, bleibt außerdem eine der wenigen „operativen“ Empfehlungen aus der Meldung: Es wird ein einfaches CLI-Kommando bereitgestellt, mit dem sich prüfen lässt, ob auf einer betroffenen Maschine in jüngster Zeit bei No-Password-Accounts ein Passwortverhalten festgestellt wurde. Das ersetzt kein vollständiges Incident-Response-Playbook, hilft aber, die Hypothese „Randbedingungen getroffen, Angriff möglich“ mit konkreten Spuren zu unterlegen. Für Entscheider heißt das: SSH-Standards (z. B. Key-only, PAM-Integration wo sinnvoll, restriktive Account-Policies) nicht nur als „best practice“ behandeln, sondern als messbare Sicherheitsarchitektur.
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "OpenSSH-Fix für „sshole“: Root über lange Passwörter auf musl-Systemen" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "OpenSSH-Fix für „sshole“: Root über lange Passwörter auf musl-Systemen" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »OpenSSH-Fix für „sshole“: Root über lange Passwörter auf musl-Systemen« bei Google Deutschland suchen, bei Bing oder Google News!