[Generic/SSH] Schwachstelle in SSH von SSH Secure Communications
(2001-07-22 09:26:41+00) Druckversion
Quelle: http://cert.uni-stuttgart.de/archive/bugtraq/2001/07/msg00487.html
Beim Verarbeiten der Dateien /etc/passwd
oder /etc/shadow
ist in der SSH-Implementation von
SSH Secure Communications ein Fehler enthalten, der bewirkt,
daß das Einloggen auf eigentlich gesperrten Accounts möglich ist.
Betroffene Systeme
- Systeme, die SSH 3.0.0 von SSH Communications Security verwenden, und die unten nicht aufgeführt sind.
- Systeme, die SSH 2.3.0 oder 2.4.0 von SSH Communications Security
verwenden, und bei denen bei der Übersetzung das Makro
HAVE_HPUX_TCB_AUTH
gesetzt ist.
Nicht betroffene Systeme
- Systeme, die SSH 2.2.0 und frühere Versionen verwenden.
- Tru64 4.0.G, NetBSD und OpenBSD sind auch mit Version 3.0.0 nicht betroffen.
- Systeme, die OpenSSH (und nicht SSH von SSH Communications Security) verwenden, sind ebenfalls nicht betroffen.
Einfallstor
SSH-Verbindung zum angegriffenen System und ein Account, bei dem in den
Systemdateien anstelle des verschlüssselten Paßwort höchstens zwei
Zeichen stehen, oder der durch das Anhängen von Zeichen an das
verschlüsselte Paßwort vermeintlich deaktiviert wurde.
Auswirkung
Kompromittierung des entsprechenden Accounts.
Gefahrenpotential
sehr hoch (Auf vielen Systemen ist mittelbar die Erlangung
von root
-Rechten möglich.)
(Hinweise zur
Einstufung
des Gefahrenpotentials.)
Beschreibung
Häufig wird auf UNIX-ähnlichen Systemen die Anmeldung für bestimmte
Benutzer verhindert, indem das in den Systemdateien
(/etc/passwd
oder /etc/shadow
) verschlüsselte
Paßwort auf zwei Zeichen oder weniger gekürzt wird. Die
SSH-Implementation von SSH Communications Security liest diese Dateien
mit eigenen Routinen ein. Beim Vergleich mit dem über das Netz
erhaltenen Authentifizierungsinformationen mit den gespeicherten
wird die Anmeldung zugelassen, auch wenn die gespeicherten Daten
länger als die erhaltenen sind. Dadurch ist es auf vielen Systemen
möglich, sich als System-Benutzer (wie bin
, lp
usw.) einzuloggen und relativ leicht indirekt root
-Rechte
zu erlangen (da beispielsweise alle Systemprogramme dem Nutzer
bin
gehören).
Gegenmaßnahmen
- Installation von SSH 3.0.1.
- Installation von OpenSSH.
crypt()
-Implementationen
weiterhin zu Problemen kommen. Außerdem ist darauf zu achten, daß
Accounts nicht durch Anhängen von Zeichen an ein eingetragenes
Paßwort deaktiviert werden, da dies auch mit SSH 3.0.1
ohne Effekt bleibt und die Anmeldung weiterhin möglich ist.
(fw)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 © 2019 RUS-CERT, Universität Stuttgart, https://cert.uni-stuttgart.de/
Vorherige Meldung | Weitere Meldungen... | Nächste Meldung |
Bitte lesen Sie auch die Grundsätze, nach denen das RUS-CERT Tickermeldungen veröffentlicht. Der regelmäßige Bezug von Tickermeldungen über E-Mail und RSS-Feed ist ebenfalls möglich.