daily.out

2009-01-30

Windows 7: UAC broken by design

Die UAC unter Windows Vista war die prominenteste Sicherheits-Neuerung in diesem Betriebssystem. Um Änderungen am System zu machen, mußte ein Administrator immerhin auf "okay" klicken, was jedoch nicht sicherstellt, ob gerade wirklich ein Administrator vor dem Rechner sitzt. Bei OS X hingegen muß man sich für so etwas per Paßwort als Administrator authentifizieren.

Microsoft hat allerdings UAC offiziell gar nicht als Sicherheitsfunktion gesehen, weil sie sagten, daß ein Fehler darin von ihnen nicht als Sicherheits-Fehler angesehen würde.

In der aktuellen Beta-Version von Windows 7 haben sie einige Änderungen an UAC vorgenommen. Die tragischste Neuerung ist, daß in der Standard-Einstellung die UAC ohne jede Rückfrage selbst ausgeschaltet werden kann.

Lang Zheng bemängelt das in seinem Artikel "Sacrificing security for usability: UAC security flaw in Windows 7 beta (with proof of concept code)". Der Höhepunkt jedoch ist: Microsoft sieht darin kein Problem, da es so "by design" gewollt ist, und will auch die finale Version von Windows 7 so ausliefern.

Lang Zheng hat auch ein Skript veröffentlicht, welches die UAC ohne irgendwelche Benutzer-Dialoge ausschaltet. Das gleiche kann auch in normalen Programmen realisiert werden.

Das bedeutet: Jedes (Schad)-Programm kann vollkommen problemlos die UAC von Windows 7 deaktivieren und dann ungehindert mit Adminstrator-Rechten, die bei Windows System-Rechten entsprechen, das System beliebig kompromittieren.

Mit UAC ermutigt Windows die Benutzer, weiterhin als zum System gleichmächtiger Windows-Administrator zu arbeiten: Seine Macht würde an sicherheitskritischer Stelle nur nach Rückfrage genutzt werden können, hieß es mit Vista. ( OS X-Administratoren sind nicht gleichmächtig mit dem System.)

Bei Windows 7 verläßt man sich weiter auf dieses Versprechen, aber der Zustand ist hier schlimmer als ohne die UAC in "XP", denn während man bei "XP" weiß, daß es keine Kontroll-Abfragen für kritische Aktionen gibt, verläßt man sich bei "7" darauf, aber sie sind nicht da, wenn man sie braucht, weil sie unbemerkt stillgelegt werden können. Der Benutzer wiegt sich in Sicherheit, läuft aber mit Windows 7 genauso Gefahr wie in "XP" nur mit dem Unterschied, daß er das nicht weiß.

Aktualisierung vom 2009-01-31

Microsoft bestätigt nochmal ausführlich: "Das soll so sein." Hatten sie nicht vor Jahren die Parole ausgegeben, daß ihnen Sicherheit so wichtig wäre?

Aktualisierung vom 2009-02-07

Am 2009-02-05 um 12 Uhr mittags bestreitet Microsoft weiterhin, daß es sich um ein Sicherheitsproblem handelt.

Am 2009-02-05 um 15 Uhr nachmittags verspricht Microsoft, das beanstandete Problem zu beheben. Als Begründung werden die vielen Proteste genannt. Und daß sie eine Änderung bereits vor den Protesten angeblich in Arbeit hatten: Die gesamten UAC-Einstellungen sollen jetzt Rückfragen auslösen.

Ich finde es bedenklich, daß außerhalb von Microsoft Leute mit klarem Verstand solche offensichtlichen Entwurfsfehler um Tage schneller begreifen als die, die Microsofts Betriebssystem entwickeln. Wundern tut mich das allerdings nicht, denn Microsoft legt sei ewigen Zeiten mehr Wert darauf, daß Entwickler und Nutzer machen können, was sie wollen, als auf Sicherheit. Ein schönes Beispiel sind hooks, die ursprünglich eingeführt wurden, um die Fehlersuche (debugging) zu erleichtern: Sie wurden von den bösen Jungs dankbar angenommen, um effiziente Schadprogramme zu schreiben: Von der systemweiten Manipulation beliebiger Programme bis zum Aufzeichnen von Tastatureingaben wird damit alles ermöglicht. Warum gibt es soviel Angriffe auf Microsoft? Weil Microsoft es by design so leicht macht.

2009-01-13

Safari-Fehler in RSS-Feed eingrenzen

Man kann es nicht oft genug wiederholen: Es kann ab einer bestimmten Programm-Größe keine Fehlerfreiheit mehr garantiert werden. Das gilt für den heimischen Rechner genauso wie für Programme in Atomkraftwerken. Während wir bei letzteren nur hoffen können, daß die Verantwortlichen diesem Umstand Rechnung getragen haben, und Fehlerfälle auffangen, sind wir im Heimbereich selbst verantwortlich.

Wenn man heute durch die üblichen Seiten im Netz blättert, dann sieht man Artikel wie diesen: Schwere Sicherheitslücke in Safari; Datenklau über RSS-Feeds. Sollte uns das erschrecken oder wundern? Nein, denn wir sind ja Realisten und rechnen mit fehlerhaften Programmen. Und so ein Netz-Blätterer gehört nunmal dazu.

Die übrigen Artikel auf anderen Seiten sind analog: Alle erzählen die böse Geschichte und liefern keine vernünftigen Vorschläge zur Abhilfe. Und alle kopieren dieselben Falschaussagen. Ich schaffe hiermit Abhilfe für beide Mißstände:

Was kann wirklich geklaut werden?

Als erstes ist anzumerken, daß diese Aussage für den Kenner dieses Betriebssystems ganz offensichtlich fehlerhaft ist:

Paßwörter werden bei OS X in der Regel im Schlüsselbund gespeichert. Selbst wenn man die entsprechenden Stellen auf der Festplatte lesen könnte, würde es dem Angreifer nichts bringen, weil die Paßwörter darin verschlüsselt sind und ohne das entsprechende Paßwort des Anwenders praktisch nicht zu entschlüsseln sind.

Der Schlüsselbund definiert auch, welche Programme zur Laufzeit Zugriff auf welche Daten im Schlüsselbund haben und auf welche nicht und wenn ja, ob eine Abfrage kommt und ob nach einem Paßwort gefragt werden soll dabei oder nicht. Das läßt sich im Schlüsselbund einsehen und einstellen, wenn man sich die Details der einzelnen Einträge anschaut. Der Angreifer könnte also auch nicht mit Safaris Hilfe allein an alle Paßworte gelangen.

Wenn der Fehler im Safari das Dateilesen und Übertragen ermöglicht, dann sind also erstmal nur die Daten des Benutzers gefährdet, die unverschlüsselt vorliegen, was normalerweise die meisten Daten betrifft, da FileVault, während man angemeldet ist, das jeweilige private Verzeichnis entschlüsselt.

Was kann man dagegen tun?

Safari einsperren. Mit der beschriebenen Methode kann man seine privaten Dokumente definitiv sicher schützen. Das läßt sich auch leicht ausprobieren, indem man versucht, mit einem solch eingesperrten Safari verbotene Verzeichnisse oder Dateien zu öffnen.

Mit diesem Sandkasten kann man garantieren, daß, selbst wenn Safari aufgrund eines Fehlers komplett unter die Kontrolle des Angreifers gerät, er sich nur in dem definierten Bereich austoben kann.

Man könnte Safari damit auch das Verzeichnis mit den Cookies verbieten, was jedoch unpraktisch ist, wenn man diese normalweise verwenden möchte. Ohne irgendwie beeinträchtigt zu werden, kann man mit so einem Sandkasten für Safari also sämtliche Daten vor seinem Zugriff schützen außer Cookies.

Die üblichen Nachrichtenseiten kopiern halt nur die Ursprungsmeldung, ohne sie technisch zu hinterfragen. Somit bieten sie dummerweise auch nur die ärgerliche Lösung an, ein anderes Programm zum Lesen von RSS-Feeds zu verwenden. Wir wissen jetzt, daß es dauerhaft besser geht, ohne das Kind mit dem Bade auszuschütten.

2009-01-11

Onkel Selles Märchenstunde. Heute: Verchromte Browser

Ende letzten Jahres hatte die MACup ein von mir gerügtes Editorial gebracht, das Spekulationen in eine falsche Richtung als Tatsachen verkaufte. Konkret ging es darum, warum es den Browser "Google Chrome" erst nur für Windows gibt. Die Wahrheit ist, wie sich jetzt herausstellt, genauso einfach wie offensichtlich.

Google hat nun erzählt, woran es unter anderem lag: Sie haben in der ersten Version eine reine Windows-Bibliothek verwendet. Es ist also kein Wunder, daß das Programm dann nicht auf anderen Plattformen laufen konnte:

Ob Stephan Selle seinen Artikel nun widerruft in einer der nächsten Ausgaben? Aber wenn juckt schon seine Schlagzeile von gestern? Was denken sich solche Journalisten? Schreiben sie Artikel schlecht recherchiert ins Blaue und hoffen, daß keiner die Details hinterfragt? Vertrauen sie darauf, daß alle ihren Artikel vergessen haben, wenn die Wahrheit herauskommt?

Diese Eigenschaften finden sich leider auch bei vielen selbsternannten "Hackern", die auf Kongressen und im Netz sich selbst und ihre Schlagzeilen wichtiger nehmen als technische Korrektheit.

---