Stabsstelle Informationssicherheit der
Universität Stuttgart (RUS-CERT)
https://cert.uni-stuttgart.de
logo
Meldung Nr: RUS-CERT-858

[Generic/OpenSSH] Schwachstelle in bestimmten Authentifizierungsverfahren
(2002-06-27 15:58:26.214152+00)

Quelle: http://www.cert.org/advisories/CA-2002-18.html

Details zur angekündigten OpenSSH-Schwachstelle wurden bereits jetzt veröffentlicht. Die Zahl der betroffenen Systeme ist weitaus geringer, als nach der Ankündigung anzunehmen war.

Betroffene Systeme

Nicht betroffene Systeme

Einfallstor
spezielle Authentifizierungspakete im Rahmen des SSH-Protokolls

Auswirkung
Es liegen glaubhafte Berichte vor, daß ein Angreifer ohne Authentifizierung beliebigen Code mit root-Rechten ausführen kann, falls BSD_AUTH oder SKEY aktiviert wurde. Für reine PAM-Systeme mit "keyboard interactive"-Authentifizierung ist dies nicht bekannt; es kann aber auch nicht ausgeschlossen werden.

Durch das Einschalten von privilege separation kann ein Angreifer nur sshd-Rechte ohne unmittelbaren Dateisystemszugriff erlangen.

Typ der Verwundbarkeit
input validation error, buffer overflow bug

Gefahrenpotential
sehr hoch, in bestimmten Umgebungen kann privilege separation das Gefahrenpotential jedoch reduzieren.
(Hinweise zur Einstufung des Gefahrenpotentials.)

Beschreibung
Die bereits am 2002-06-25 von den OpenSSH-Entwicklern angekündigte Schwachstelle wurde entgegen der Ankündigung bereits am 2002-06-26 en detail beschrieben. Es handelt sich um Fehler im Programmcode betimmter Authentifizierungsmethoden, welche im wesentlichen alle interaktiv sind: Es wird nicht nur ein einzelnes Token zur Authentifizierung übermittelt (z.B. ein Paßwort), sondern es findet ein (im Prinzip) bidirektionaler Nachrichtenaustausch zwischen Client und Server statt. Betroffen von diesem Fehler sind:

BSD_AUTH ist lediglich auf BSD-Systemen einkompiliert, SKEY ist ebenso hauptsächlich dort anzutreffen. Die dritte Methode ist eine bestimmte Spielart von PAM, erfordert also einkompilierte PAM-Unterstützung. Nach der Installation der portablen OpenSSH-Distribution ist dieses Feature zunächst abgeschaltet und muß explizit eingeschaltet werden. (Hinweis: Es gibt auch S/Key-Authentifizierung in Form PAM-Moduls, welches entgegen der ursprünglichen S/Key-Philosophie auf die Challenge-Nachricht verzichtet und daher auch ohne den "keyboard interactive"-Modus funktioniert. Der bloße Einsatz eines derartigen PAM-Moduls macht an sich einen SSH-Server nicht anfällig für die beschriebenen Schwachstellen.)

Bei Systemen mit BSD_AUTH- bzw. SKEY-Unterstützung sind funktionierende Angriffsprogramme verfügbar, die (falls privilege separation nicht aktiviert ist) einem Angreifer root-Rechte auf dem angegriffenen System geben, ohne daß dieser sich vorher authentifizieren muß. Für die PAM/"keyboard interactive"-Schwachstelle ist dies ebenfalls zu erwarten.

Bezüglich der betroffenen Systeme ist folgendes anzumerken: OpenSSH 1.2.3 unterstützt Version 2 des SSH-Protokolls nicht und enthält daher auch nicht den von der Schwachstelle betroffenen Programmcode. Bevor das Not-Upgrade auf OpenSSH 3.3.p1 durchgeführt wurde, war Debian GNU/Linux stable also von der Schwachstelle nicht betroffen, nach dem Upgrade bei entsprechender Konfiguration dagegen durchaus. (Dies ist allerdings nicht die Schuld der Debian-Entwickler.)

Hinweis: Auf der OpenSSH-Webseite ist derzeit folgende Warnung zu lesen:

The 3.4 release contain many other fixes done over a week long audit started when this issue came to light. We believe that some of those fixes are likely to be important security fixes. Therefore, we urge an upgrade to 3.4.
Gegenwärtig wird von verschiedener Seite geprüft, ob neben der PAM-Problematik (die in den ersten detaillierten Advisories nicht erwähnt wurde) weitere kritische Korrekturen eingeflossen sind, die bisher nicht erwähnt wurden.

Workaround

Hinweis: Der Einsatz von OpenSSH 3.3 mit privilege separation eliminiert laut CERT/CC die Schwachstelle nicht. Falls Systeme die Schwachstelle vorher aufwiesen, werden die Auswirkungen lediglich abgemindert. Trotz chroot in ein leeres Verzeichnis und fehlender root-Privilegien kann ein Angreifer immer noch auf (móglicherweise ungesicherte) Dienste auf locahost zugreifen, das Netz nutzen (z.B. als Spam-Relay oder Brückenkopf für weitere Angriffe), oder über Kernel-Bugs doch root-Rechte erlangen.

Privilege separation kann tatsächlich eine Klasse von Angriffen eliminieren (nämlich die meisten, die sich nach der Authentifizierung des Benutzers abspielen, zum Beispiel solche, die auf einer Schwachstelle in der Channel-Verarbeitung basieren). Wenn privilege separation funktioniert (die Zusammenarbeit mit einer ganzen Klasse von PAM-Modulen ist beispielsweise derzeit nicht möglich), sollte diese Funktionalität daher aktiviert werden. Als Gegenmaßnahme für das aktuelle Problem ist sie jedoch nicht ausreichend.

Gegenmaßnahmen

Weitere Information zu diesem Thema

Revisionen

(fw)

Weitere Artikel zu diesem Thema:

Hinweis
Die in diesem Text enthaltene Information wurde für die Mitglieder der Universität Stuttgart recherchiert und zusammengestellt. Die Universität Stuttgart übernimmt keinerlei Haftung für die Inhalte. Dieser Artikel darf ausschließlich in unveränderter Form und nur zusammen mit diesem Hinweis sowie dem folgenden Copyrightverweis veröffentlicht werden. Eine Veröffentlichung unter diesen Bedingungen an anderer Stelle ist ausdrücklich gestattet.

Copyright © 2022 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/


https://cert.uni-stuttgart.de/ticker/article.php?mid=858