[Technik] [SECURITY] [DSA 1576-1] New openssh packages fix predictable randomness

[Paul Hink]

Peter Koellner <peter at asgalon.net> wrote:

> On Fri, 16 May 2008, Paul Hink wrote:
> 
> > Nein. Die Verschlüsselung einer ssh-Verbindung basiert nicht auf
> > dem Login-Passwort des Users.
> 
> Äh... und wie sieht es mit dem Host-key aus?

Der spielt natürlich eine wichtige Rolle bei der Sicherung einer
SSH-Verbindung. Aber das hat nichts mit alten oder neuen Passwörtern
irgendwelcher Accounts zu tun.

> > Was für Maßnahmen schlägst du konkret für Hostsharing vor?
> 
> Gute Frage. Das selbe Problem stellt sich auch für andere Server, auf
> denen ich zu tun habe. Wenn ich mal ganz misstrauisch bin, würd ich
> mich als erstes fragen, ob die Debian-Server mit den Paketen sicher
> sind, so dass man eine Vergleichsbasis für einen sauberen Stand hätte.
> Die sind ja eigentlich alle mit GPG signiert - fragt sich bloss, ob
> die Sourcen an irgendeiner Stelle manipuliert werden konnten.
> Ist das nicht der Fall, fällt Debian leider bis zur Bereinigung als
> Basis aus, so gern ich das auch sonst verwende.
> Wenn sichergestellt ist, dass die Originalpakete nicht kompromittiert
> werden konnten, könnte man wohl checken, ob die binaries korrekt oder
> manipuliert sind,

Was aber selbstverständlich nur mit Downtime ginge, jemand müsste ins
RZ, die Server von einem externen Medium booten, die System-Binaries
prüfen. Okay, damit hätten wir einen möglichen Angriffsvektor
ausgeschaltet. Dann ginge es weiter mit zig Konfigurationsdateien,
Hostsharing-eigenen Scripts, selbstcompilierter Software etc. Ganz zu
schweigen von den Konfigurationsdateien, Software-Installationen etc.
in den Hostsharing-Paketen. Und den Sachen, die mir jetzt aus dem
Stehgreif nicht direkt einfallen.

Sorry, so gerne ich persönlich eine derartige gründliche Prüfung sehen
würde, das können wir (und mit uns sicher sehr viele andere
Serverbetreiber) einfach nicht leisten. Schon gar nicht, wenn uns wie
in diesem Fall praktisch jede Grundlage fehlt und wir z.B. alle
Konfigurationsdateien von Grund auf manuell prüfen müssten, einfach
weil alle potentiellen Vergleichsdaten ebenfalls auf Systemen liegen,
auf denen unsichere OpenSSL/OpenSSH- Versionen eingesetzt waren.

> Ansonsten muss man wohl jenseits dieser Ad-Hoc-Spekulationen
> herausfinden, was wirkich notwendig ist, um die Betriebssicherheit
> entsprechend eines konsensfähigen Standards wiederherzustellen.
> Mit extrem hohem Standard würde man da wohl die Platten
> formatieren und von vorne anfangen.

Ja. Dann könnten wir die Hostsharing e.G. auflösen und ganz von vorne
anfangen.

> Es wäre also nicht schlecht, das ganze in Risikogruppen aufzuteilen
> und dann zu beschliessen, wie weit man gehen will oder sollte.
> 
> Das ist immer noch nicht sehr konkret. Ich denke, man kann nicht
> den Leuten sagen, sie sollen ihre Schlüssel austauschen und dann zur
> Tagesordnung übergehen.

Auch wenn dir jetzt vielleicht keine konkreten Maßnahmen einfallen: In
welche Richtung denkst du (oder andere Mitlesende) denn, sollten wir
weitergehende Maßnahmen ergreifen? (Diese Frage ist absolut ernst
gemeint, wenn jemandem was gutes einfällt, immer her damit!)

> Nun würde ich mich auch nicht unbedingt als den großen
> Sicherheitsexperten bezeichnen, deshalb brauche ich auch
> Informationen von Leuten, die sich in der Praxis auskennen. Ich denke
> eben, dass Sicherheitssysteme niemals auf Vertrauen basieren können,
> sondern allein auf der Schwachstellenanalyse.
> 
> Der worst case ist ja, dass irgendwann Mitte 2006 jemand mitbekommen
> hat, was da passiert ist und seitdem gezielt auf breiter Basis debian
> Systeme ausspioniert und unterwandert.
> 
> Der best case ist, dass Luciano Bello der erste ist, der darüber
> gestolpert ist. In dem Fall sind lediglich gezielte Angriffe auf
> verwundbare Systeme seit Veröffentlichung des Advisories zu erwarten.

Das ist klar. Es hilft uns aber leider wenig, wenn es darum geht, wie
wir jetzt weitermachen soll(t)en/wollen.

Paul