Kritischer Bug in SuSE Linux 9.1

In den letzten drei Jahren entwickelte ich ein System, um Passwörter einfacher und effizienter verwalten zu können. Da ich mich hierzu natürlich intensiv mit Passwortsystemen beschäftigen und auseinander setzen musste, bin ich wahrscheinlich für den unten beschriebenen Bug, oder besser gesagt für das aus ihm resultierenden Angriffsszenario, besonders sensibilisiert. Dies würde auch erklären, dass anscheinend vor mir niemand diesen Bug hier als recht bedeutsam erachtete, obwohl SuSE 9.1 ja schon seit fast genau zwei Monaten im Handel ist.

Im Rahmen des Versionswechsels von 9.0 auf 9.1 stellte SuSE auf UTF-8 als Codetabelle um. Insbesondere die Zuordnung der Umlaute und Sonderzeichen verschob sich dadurch, so dass z.B. Dateinamen mit Umlauten, welche mit einer vorherigen Version erstellt wurden, nicht mehr richtig lesbar sind.

Viel bedeutsamer als solche kleinen Unannehmlichkeiten ist aber, dass infolge des Wechsel der Codetabelle unter KDE, welcher ja bekanntlich den Standarddesktop bei SuSE verköpert, Umlaute und Sonderzeichen in Passwörtern unter Umständen nicht mehr richtig übermittelt werden können. Bei der Eingabe von Umlauten und auch bestimmten Sonderzeichen in das entsprechende Fenster von KDE werden anstatt von einem ein Zeichen ZWEI Zeichen generiert. Zwar wird, wenn unter SuSE 9.1 neue Passwörter im Rahmen der Rechteverwaltung angelegt werden, dieser Fehler durch entsprechende Ausschlusskriterien abgefangen. Aber die entsprechenden Einschränkungen bestanden in vorherigen Versionen nicht, so dass man sich bei alten Passwörtern unter Umständen nicht mehr über den KDE Desktop ordnungsgemäß autorisieren kann, obwohl man das richtige Passwort eingegeben hat.
Dass deswegen möglicherweise über den KDE Desktop die Autorisation als Super-user root nicht mehr funktioniert, mag ja noch zu verschmerzen sein. Man kann sich ja inzwischen wieder direkt gleich als Super-user root einloggen. (Ich glaube es war SuSE Linux 8.1, an dem dies über die graphische Benutzeroberfläche nicht mehr möglich war.) Außerdem kann man ja das Root-Passwort entsprechend den neuen Gegebenheiten angleichen.
Leider wird über das schon erwähnte Eingabefenster auch der Autorisationsdialog mit Kgpg, dem graphischen KDE Frontend zum Verwalten von gpg Schlüsseln (!), abgewickelt. Da hier die Verwendung von Sonderzeichen ausdrücklich angeraten wird, dürften in diesem Fall die durch diesen Bug entstehenden Einschränkungen schon beträchtlich mehr ins Gewicht fallen.
Besonders fatal dürfte allerdings sein, dass auch Kdewallet, der KDE Passwortmanager, von diesem Bug betroffen ist. Folglich gibt man Passwörter unter Umständen in Websiten und anderen passwortgeschützten Systemen in anderer Form ein als man dies in Kdewallet tut. Die Folgen von so etwas kann sich ja jeder selbst ausmalen.

Auf technischen Weg lässt sich der hier beschriebene Bug wahrscheinlich (und auch hoffentlich) nicht ausbeuten. Für Angriffsmöglichkeiten im Rahmen von Ansätzen des so genannten social engeneering ist er allerdings geradezu prädestiniert.
Eine bei der Ausspionierung von Passwörtern oftmals angewandte psychologisch-soziale Methode ist es, das potentielle Opfer in einen krisenhaften Ausnahmezustand zu versetzen. Da der/die Betroffene in diesem Fall wegen der Notsituation automatisierte Handlungsabläufe verlassen muss, und beträchtlich unter Stress gerät, werden dann nämlich unter Umständen regulär angewandte Sicherheitsmaßnahmen außer Kraft gesetzt, und ein eventueller Angriff erleichtert, bzw. erst ermöglicht.
Beim klassischen Hackerangriff auf den CIA Rechner im Film "Mission Impossible" (Tom Cruise hängt wie eine Spinne über dem Rechner), um ein Beispiel aus der "Literatur" zu nennen, wurde diese Methode z.B. sogar zweimal angewandt: Zunächst wurde ein Fehlalarm ausgelöst. Dadurch war es möglich, fremde Personen als Feuerwehrleute verkleidet in das Gebäude zu schleußen, ohne dass diese die ansonsten üblichen Sicherheitkontrollen durchlaufen mussten. Sodann wurde dem Mitarbeiter, der die Benutzung des Zielrechners innehatte, ein Medikament appliziert, welches bei ihm, gerade als er am Rechner saß, eine große Übelkeit auslöste. Infolge dieser Übelkeit sah er sich genötigt, den Rechner unbeaufsichtigt zu lassen, ohne ihn noch ordnungsgemäß herunterfahren zu können. Dadurch konnte Tom Cruise überhaupt erst unbemerkt auf diesen Rechner zugreifen, und die benötigen Daten von ihm herunter kopieren.

Wenn jemandem nach der Eingabe von Passwörtern eine Zugriffsverweigerung zurückgemeldet wird, geht er wahrscheinlich zunächst einmal davon aus, dass er das Passwort falsch eingegeben hat. Er also selbst einen Fehler gemacht hat. Externale Faktoren, also z.B. wie hier, dass die Tastatureingaben falsch interpretiert werden, schließt er auch nach weiteren Fehlversuchen zunächst einmal aus. Denn gerade unter diesen spezifischen Umständen hier dürfte einem so etwas ja als recht unwahrscheinlich erscheinen. Vorher nämlich, als das System noch nicht auf SuSE 9.1 upgedatet war, hat ja noch alles einwandfrei funktioniert. Auch dass nach der Eingabe von Sonderzeichen und Umlauten zwei Sternchen anstatt von einem im Eingabefeld auftauchen, kann man sehr leicht übersehen.
Nach mehrmaligen Auftreten solcher Fehlermeldungen wird die betroffene Benutzerin bzw. der betroffene Benutzer deswegen mit großer Wahrscheinlichkeit die gemachten Eingaben zu verifizieren suchen, also dass sie bzw. er z.B. auf schriftliche Aufzeichnungen des entsprechenden Passwortes zurückgreift. Dazu müssen die entsprechenden Passwortdaten aus ihrer gesicherten Umgebung herausgelöst werden. Die entsprechenden Aufzeichnungen müssen also z.B. aus einem Tresor genommen werden, oder eine verschlüsselte Datei, welche des Passwort enthält, muss entschlüsselt werden. Gerade dann, wenn dies geschehen, könnten sich Möglichkeiten ergeben, dass Passwort auszuspionieren.
Es könnte sogar möglich sein, dass in diesem Fall versucht wird, über eine entsprechde Notzugriffsprozedur wieder Systemzugriff zu erlangen. Unter SuSE Linux kann man z.B. durch Löschung des entsprechenden Links in der Datei passwd einen root Zugriff ermöglichen, ohne dass hierzu ein Passwort eingegeben werden muss. Leider ist diese Maßnahme, wie ich schon am eigenen Leib erfahren durfte, nicht mehr reversibel. Es muss also dannach, soweit ich informiert bin, um den root acount wieder mit einem Passwort sichern zu können, das Betriebssystem gänzlich neu aufgespielt werden. Mit diesem Bug nun könnte man unter Umständen jemanden so weit bringen, dass er den Root-Account auf diese Weise öffnet. Dann wäre der betroffene Rechner mit Sicherheit über einige Tage hinweg sehr stark ungesichert, was sich natürlich auch wieder entsprechend ausnutzen ließe.
Sicher dürfte es noch hundert andere Möglichkeiten geben, wie man diesen Bug missbrauchen könnte. Ich will es aber bei diesem einem Beispielen belassen. Zeigt sie doch alleine schon recht eindringlich und plastisch, was für eine Bedrohung für Computersysteme der hier beschriebene Bug unter Umständen darstellen kann!!