Nicht ‘trustworthy’

Internet Explorer gefährdet Rechner und Netze

Wissen | Hintergrund

Anfang des Jahres gab Bill Gates den Startschuss zu seiner Trustworthy-Computing-Kampagne, mit der Sicherheit bei Microsoft einen höheren Stellenwert bekommen sollte. Doch an der (Un-)Sicherheit mancher Microsoft-Produkte hat das bisher nicht viel geändert. Das zuletzt entdeckte Sicherheitsloch im Internet Explorer gefährdet nicht nur Daten auf dem Rechner des Surfers, sondern auch in lokalen Netzen.

Politikern gibt man traditionell 100 Tage Schonfrist, Microsofts Trustworthy-Computing-Kampagne ist schon fast ein Jahr alt. Das fällige Resümee fällt vernichtend aus: Die Frequenz, mit der neue Sicherheitslücken in Microsoft-Produkten gefunden werden, ist nicht merklich gesunken - im Gegenteil.

Trauriger Spitzenreiter der Bug-Charts ist nach wie vor Microsofts Internet Explorer, der zum Standard-Browser der meisten Internet-Nutzer avanciert ist - und zum größten Sicherheitsrisiko. Zwischenzeitlich führte Thor Larholm auf seiner Website [1] bis zu 32 nicht behobene Sicherheitslücken auf. Den vorläufigen Höhepunkt markiert ein von Andreas Sandblad aufgezeigtes Loch, das es erlaubt, beliebige Kommandos auf dem Rechner eines Surfers auszuführen.

Es genügen wenige Zeilen JavaScript-Code, um Besuchern von Websites eine Falle zu stellen. Die Demonstration auf den c't-Browsercheck [2] öffnet ein paar Fenster und schließlich eine DOS-Box, die ein Festplattenverzeichnis und eine Meldung ausgibt. Die Demonstration könnte genauso gut Festplatten formatieren oder Dateien löschen und funktioniert mit dem Internet Explorer 5.5 oder 6, der mit allen bis zum 19. 11. verfügbaren Sicherheits-Updates von Microsoft versehen ist.

Mit ein paar Änderungen am Beispiel-Code bauten wir für interne Tests eine besonders hinterhältige, scharfe Version: Wählt ein Surfer diese URL an, erscheinen lediglich ein paar Fenster. Erst beim nächsten Anmelden am System beginnt ein Prozess, im Hintergrund Dateien zu löschen. Er zerstört alles, worauf der angemeldete Benutzer Schreibrechte hat: Word-Dokumente genauso wie Systemdateien.

Hier geht es nicht mehr um scheinbaren ‘Kinderkram’ wie Cookies auszulesen oder den Taschenrechner zu starten. In einem Firmennetz kann das Sicherheitsloch zu einer richtigen Katastrophe führen. Hat der Benutzer Schreibrechte auf gemeinsam genutzten Verzeichnissen eines Servers oder auf Rechnern von Kollegen, kann das Skript binnen kürzester Zeit die gemeinsame Arbeitsgrundlage zerstören und damit den Produktionsbetrieb nachhaltig lahm legen. Und dagegen schützt keine noch so gut konfigurierte Firewall - sofern sie nicht JavaScript ausfiltert. Das dürfte aber selten der Fall sein, da mittlerweile viele Seiten ohne JavaScript gar nicht mehr funktionieren.

Man stelle sich folgendes Szenario vor: Demnächst taucht ein Sicherheitsproblem in Microsofts Web-Server, dem Internet Information Server (IIS) auf. Das benutzt ein Wurm, um den gefährlichen JavaScript-Code auf tausende Internet-Sites im ganzen Netz zu verteilen. Unrealistisch? Denken Sie an Code Red oder Nimda, die genauso vorgingen. Und schon diese vergleichsweise harmlosen Würmer verursachten Milliardenschäden - bei den Windows-Anwendern, nicht bei Microsoft wohlgemerkt.

Am 20. 11. hat Microsoft einen Patch herausgegeben, der angeblich ‘alle bekannten sowie neu entdeckte Sicherheitslücken’ schließt (MS02-066). Zwar funktioniert damit der Sandblad-Exploit in der veröffentlichten Form nicht mehr. Doch wer sich jetzt sicher wähnt, sitzt einem gefährlichen Irrtum auf. Allein von den neun kürzlich durch Greymagic veröffentlichten Sicherheitslücken sind drei nicht behoben, mit mindestens einer kann man externe Programme starten. Andreas Sandblad erklärte gegenüber c't, dass der Exploit zum Ausführen externer Programme, den er vor einem Monat an Microsoft übermittelt habe, bei ihm trotz Patch immer noch funktioniere. Dieser unterscheidet sich nur in einem Detail von der publizierten Variante, sodass wohl bald eine entsprechend modifizierte Version auftauchen wird.

Auch wenn Microsoft diese Lücken ebenfalls schließt, ist die Gefahr noch längst nicht vorbei. Die Erfahrungen mit Nimda und Code Red haben gezeigt, dass selbst auf Servern nach Monaten Patches nicht überall installiert sind. Bis alle Endanwender - oder zumindest die Mehrzahl - auf ihren PCs Updates eingespielt haben, kann es Jahre dauern. Der Internet Explorer ist bis dahin ein massives Sicherheitsrisiko - insbesondere in Unternehmensnetzwerken.

Dass beim Internet Explorer viel mehr Sicherheitslücken als bei den Konkurrenten bekannt werden, liege daran, dass er das bevorzugte Ziel der Hacker sei - argumentieren seine Fans gerne. Wenn alle Welt mit Mozilla surfen würde, käme dieser nicht besser weg.

Es mag stimmen, dass mehr Hacker den Internet Explorer auf Sicherheitslücken abklopfen als die so genannten Exoten. Andererseits haben sie dabei auch mit deutlich mehr Schwierigkeiten zu kämpfen als bei einem Open-Source-Projekt wie Mozilla. Dort verrät im Zweifelsfall ein Blick in den Quelltext, ob und wie man eine Merkwürdigkeit im Verhalten ausnutzen kann. Diesen kann man auch systematisch auf bekannt kritische Code-Sequenzen absuchen.

Außerdem greift die Erklärung zu kurz. Denn schon das Design des Internet Explorer weist zwei große Schwachstellen auf: Active Scripting und ActiveX sind für nahezu alle IE-Sicherheitsprobleme der letzten Jahre verantwortlich - und beide gibt es in dieser Form bei den Konkurrenten nicht.

Microsoft hat den Internet Explorer sehr weit in das Betriebssystem integriert. So nutzen auch Systemprogramme wie die Hilfe oder der Desktop den Browser. Dazu hat Microsoft dessen Fähigkeiten sehr stark erweitert und JavaScript zu einer vollwertigen Programmiersprache ausgebaut. Die Microsoft-Version JScript ist genauso mächtig wie VBS und kann über ein FileSystemObject Dateien öffnen oder löschen, Programme starten, mit existierenden Prozessen kommunizieren und so weiter - obwohl man vieles davon für einen reinen Web-Browser gar nicht bräuchte.

Eine Möglichkeit, die gefährlichen Funktionen zumindest beim Surfen im Internet abzuschalten, hat Microsoft nicht vorgesehen: Active Scripting gibts entweder ganz oder gar nicht. Netscapes JavaScript hingegen ist viel beschränkter: Es kennt schlicht kein FileSystemObject - und damit auch keinen direkten Zugriff auf lokale Dateien des Rechners.

Ein weiteres IE-spezifisches Übel - zumindest aus der Sicherheitsperspektive - ist die Integration von ActiveX. Grob vereinfacht kann jedes dafür vorgesehene Programm auf einem Windows-Rechner auch als ‘Objekt’ agieren. Diese Objekte - ActiveX-Controls genannt - können mit anderen Objekten kommunizieren, diese steuern oder selbst gesteuert werden. So nutzt der Internet Explorer das ActiveX-Control Media Player, um MP3-Dateien abzuspielen, und Outlook Express vermag mit dem Internet Explorer HTML-Mails anzuzeigen.

Auf jedem Windows-System gibt es Dutzende von Controls, die als ‘Safe for Scripting’ gekennzeichnet sind. Das hat zur Folge, dass in der Standardeinstellung JScript-Code in einer Webseite diese Controls aufrufen und beliebig fernsteuern kann. Die Markierung beschränkt aber nicht etwa den Funktionsumfang. Sie bekundet lediglich, dass sich die Entwickler sicher waren, dass ihr Programmcode kein Risiko darstellt. Immer wieder tauchen jedoch Sicherheitsprobleme mit solchen ‘sicheren’ Controls auf, die beweisen, dass die Entwickler mit dieser Einschätzung danebenlagen.

Wie schwer man unsichere ActiveX-Controls los wird, demonstrierte Microsoft unfreiwillig selber: In einem Security Bulletin zur fehlerhaften Datenbankzugangskomponente MDAC (MS02-065) räumten die Redmonder ein, dass Angreifer über eine Webseite oder eine E-Mail den MDAC-Patch wieder rückgängig machen und das alte, fehlerhafte Control wieder installieren könnten, denn es trägt eine gültige Signatur von Microsoft. Um das zu verhindern, müsse man von Hand alle Herausgeber-Zertifikate entfernen.

Bei anderen Browsern übernehmen spezielle Plug-ins die Rolle der ActiveX-Controls. Diese Plug-ins bringen prinzipiell ähnliche Risiken mit sich: Ein Sicherheitsloch im Flash-Plug-in von Mozilla könnte ebenfalls verheerende Folgen haben. Doch bei den Plug-ins handelt es sich um vergleichsweise wenige, spezielle Erweiterungen, die sich auch einzeln deaktivieren oder sogar entfernen lassen, ohne dass es die Funktionsfähigkeit des Systems insgesamt beeinträchtigen würde. ActiveX-Objekte hingegen befinden sich auf jedem Windows-System zu Hunderten, und der IE-Benutzer kann sie weder einzeln an- und ausschalten noch mit einfachen Mitteln deinstallieren.

Als Sicherheitsbarriere dient vor allem die so genannte Cross-Site-Scripting-Policy. Sie besagt, dass ein Skript von einer Webseite keinen Zugriff auf Dokumente oder Objekte erlangen darf, die von einem anderen Server stammen oder in einem anderen Sicherheitskontext - etwa dem des lokalen Rechners - gestartet wurden. Sonst könnte ein Skript einfach ein neues Fenster mit einer lokalen URL öffnen und dieses so fernsteuern, dass es beispielsweise Dateien löscht.

Doch wie es alle künstlichen Grenzen an sich haben, ist auch diese löchrig: Viele der in letzter Zeit veröffentlichten Sicherheitslücken im IE beruhen auf Löchern in der Cross-Site-Scripting-Policy. Der Sandblad-Exploit nutzt eines davon, um über ein im Internet Explorer angezeigtes Hilfefenster beliebige Befehle auszuführen.

Insgesamt verwischt der Internet Explorer zunehmend die Grenze zwischen dem Arbeiten am lokalen Rechner und dem Surfen im Internet. Damit einher geht ein Spagat zwischen lokaler Allmacht und sicherem Surfen, der nicht gelingen kann.

Wer Sicherheit oben anstellt, hat derzeit nur zwei Alternativen: auf Browser wie Opera oder Mozilla umsteigen (siehe c't 25/2002, Seite 106) oder Active Scripting zumindest beim Surfen im Internet deaktivieren (siehe c't 25/2002, Seite 102). Und unter dieser Prämisse - also beispielsweise Mozilla mit JavaScript oder Internet Explorer ohne - gewinnt der Alternativ-Browser auch jeden Vergleich bezüglich Komfort und Funktionsvielfalt.

Auch für die jetzt noch offenen Sicherheitslücken wird Microsoft sicher früher oder später einen Patch liefern. Aber genauso sicher werden neue Lücken bekannt werden. Ohne grundsätzliche Änderungen am Design und wohl auch an Microsofts Firmenpolitik wird es keinen sicheren Internet Explorer geben.

Der Sicherheitsexperte Bruce Schneier hat nach dem Start von Microsofts Sicherheitsinitiative eine Liste von Punkten zusammengestellt, an denen Microsoft arbeiten müsse und an deren Umsetzung sich die Bemühungen der Redmonder messen lassen sollten [3]. Sie enthalten neben eher technischen Forderungen wie der nach strikter Trennung von Code und Daten auch die nach mehr Transparenz. Bisher ist keiner der sieben Punkte wirklich umgesetzt - Microsoft wäre jedoch gut beraten, sich diesen Katalog noch einmal gut anzusehen. (ju)

[1] Liste ungepatchter IE-Löcher: www.pivx.com/larholm/unpatched

[2] c't Browsercheck

[3] Bruce Schneier: www.counterpane.com/crypto-gram-0202.html

Kommentare