Das Sicherheitsunternehmen Qualys hat eine als kritisch eingestufte Lücke in OpenSSH entdeckt. Der Fehler steckt in einer „experimentellen“ Funktion des Programmpakets, das als Standard-Implementation von SSH in der Unix-Welt gilt. Sie soll es Nutzern erlauben, Verbindungen wieder aufzunehmen. Einem Eintrag in einer Mailing-Liste zufolge könnte ein speziell eingerichteter Server einen OpenSSH-Client dazu bringen, den Inhalt seines Speichers und damit auch die privaten Schlüssel des Clients preiszugeben.
Betroffen sind die OpenSSH-Versionen 5.4 bis 7.1. Sie werden unter anderem von OpenBSD, FreeBSD und diversen Linux-Distributionen wie Debian, Ubuntu 12.04, 14.04, 15.04 und 15.10 sowie Red Hat Enterprise Linux 7 (RHEL) eingesetzt. Darüber hinaus ist auch Mac OS X anfällig. „Da Apple normalerweise Sicherheitsfixes verzögert, raten wir dazu, den Workaround anzuwenden“, heißt es in der Mailing-Liste.
Nutzer, die noch keinen Zugriff auf einen Patch haben, können ihrer SSH-Konfiguration den Eintrag „UseRoaming no“ hinzufügen oder ihren SSH-Client mit der Option „-oUseRoaming=no“ über die Eingabeaufforderung starten. Dadurch wird die fragliche experimentelle Funktion vollständig abgeschaltet. OpenSSH-Server sind laut OpenBSD nicht von der Anfälligkeit betroffen, da der Server-Code nie ausgeliefert worden sei.
Patches stehen ab sofort für OpenSSH 5.7 und 5.8 zur Verfügung. Der Mailing-Liste zufolge enthalten Portable OpenSSH 7.1p2, sowie Snapshots für OpenBSD ab 12. Januar 2016 einen Fix. Für die meisten Linux-Distributionen sei das Update ebenfalls ab sofort oder in Kürze erhältlich.
Wie eine optimale IT-Infrastruktur für UCC-Lösungen die Produktivität Ihrer Mitarbeiter steigert
Das Webinar “Wie eine optimale IT-Infrastruktur für UCC-Lösungen die Produktivität Ihrer Mitarbeiter steigert” informiert Sie über die Vorteile einer Unified Communications & Collaboration-Lösung (UCC) und skizziert die technischen Grundlagen, die für die erfolgreiche Implementierung nötig sind. Jetzt registrieren und die aufgezeichnete Fassung des Webinars ansehen.
Laut Wolfgang Kandek, Chief Technology Officer bei Qualys, hat sein Unternehmen die OpenSSH-Entwickler am 11. Januar über die Schwachstelle informiert. Der Patch sei daraufhin in nur drei Tagen entwickelt worden. Allerdings veröffentlichte Qualys gestern auch Beispielcode für einen Exploit, was den Druck auf OpenSSH-Nutzer erhöht, die verfügbaren Patches so schnell wie möglich einzuspielen.
Der Sicherheitsexperte Kenneth White befürchtet, dass die SSH-Schlüssel von Hunderttausenden von Linux-Servern weltweit in Gefahr sind. Außer Linux-Servern seien außerdem viele Router und Firewalls betroffen. Er rät Administratoren von betroffenen Systemen, egal ob es sich um Hobby-Projekte oder Server mit vertraulichen Daten handelt, die SSH-Schlüssel neu zu generieren oder zu tauschen.
[mit Material von Zack Whittaker, ZDNet.com]
Neueste Kommentare
2 Kommentare zu Kritische Sicherheitslücke in OpenSSH gefährdet private Schlüssel
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Eine Frage an die „Profis“:
Was bedeutet das konkret für einen Mac-Nutzer?
Wann/Wie ist man betroffen? Was sollte man genau dagegen tun???
Ist m.E. auch etwas kryptisch beschrieben, aber hier steht was passiert: „Einem Eintrag in einer Mailing-Liste zufolge könnte ein speziell eingerichteter Server einen OpenSSH-Client dazu bringen, den Inhalt seines Speichers und damit auch die privaten Schlüssel des Clients preiszugeben.“
Bedeutet: Grundsätzlich ist das nur für SSH Nutzer wichtig, bzw. auch falls man eine Anwendung nutzt, die auf SSH aufsetzt – d.h. …
– wenn Du a. keinen SSH Client nutzt –> keine Gefahr. – wenn Du b. einen SSH Client nutzt, aber z.B. nur intern in Deinem eigenen, abgesicherten Netzwerk –> keine Gefahr.
– wenn Du c. einen SSH Client nutzt, und damit im Internet nur dedizierte, Dir bekannte Server anwählst –> keine Gefahr, sofern Deine Anfrage nicht umgeleitet wird, m.E. eine sehr geringe Gefahr
– wenn Du Dich d. mit Deinem SSH gerne auf unbekannten Internet Servern bewegst, solltest Du mindestens das Wrkaround einsetzen, d.h. die oben genannten Optionen beim Start und in der Config Datei.
Sollte ich das falsch einschätzen, kann das gerne jemand korrigieren/ergänzen.