Internet Explorer an die Kette gelegt

Inhaltsverzeichnis

IEController ist ein Sandbox-Programm, das den Internet Explorer von Windows abschottet. Es verhindert zuverlässig, dass aktive Inhalte, die aus dem Web geladen werden, auf Ihrem PC Schaden anrichten oder Daten ausspionieren. Seine Filterlisten stellen sicher, dass ungefährliche Inhalte auch weiterhin ausgeführt werden. Das Surfen wird dadurch erheblich sicherer, ohne dass Sie dafür auf den Komfort moderner Web-Techniken, Plug-ins und anderer Browser-Erweiterungen verzichten müssen.

IEController 1.0 läuft unter Windows 2000/XP und .NET Server. Für Windows NT wäre eine Anpassung nötig; unter Windows 9x kann die angewandte Methode nicht funktionieren. Wir haben das Programm mit dem Internet Explorer 5.5 und 6.0 und den dazugehörigen Service-Packs getestet.

Version 1.0 besitzt kein Setup-Programm, sondern wird einfach in ein Verzeichnis kopiert und von dort gestartet. IEController nimmt keinerlei Eingriffe in den Internet Explorer oder das Betriebssystem vor. Es speichert lediglich sein Regelwerk in der Registry (unter dem Schlüssel ‘c't’). Generell gehen Sie mit der Installation von IEController kein Risiko ein. Wenn etwas nicht funktioniert, können Sie den Internet Explorer jederzeit direkt starten, wobei das Tool nicht aktiv wird. Das empfiehlt sich etwa, um Patches und Updates von http://windowsupdate.microsoft.comzu installieren.

Im Unterschied zu anderen Sandbox-Tools fängt IEController nicht bestimmte Zugriffe von laufenden Skripten, Plug-ins und Controls auf Systemressourcen ab, sondern setzt den Hebel eine Ebene tiefer an: Es verhindert den Start der zur Ausführung bestimmter aktiver Inhalte notwendigen Module. Der Internet Explorer besteht nämlich nicht aus einem Programmblock, sondern startet bei Bedarf Module in Form von COM-Objekten (Component Object Model) nach. Etwa beim Laden einer Webseite, die JavaScript-Code enthält, öffnet der Internet Explorer die Datei ‘jscript.dll’ und erzeugt ein COM-Objekt, das den Code ausführt.

COM-Stopp

An dieser Stelle schaltet sich IEController ein. Das Programm arbeitet als Loader, der den Internet Explorer startet. Es kann sich so in die Windows-Funktionen einklinken, die für die Erzeugung von COM-Objekten verantwortlich sind (CoCreateInstanceEx und CoGetClassObject). Sobald der Browser diese Funktionen aufruft, entscheidet IEController, ob das Objekt mit der angegebenen Kennung (CLSID) erlaubt ist oder nicht. Falls ja, reicht das Programm den Aufruf an die ursprüngliche Windows-Funktion weiter, andernfalls gibt es einen Fehlercode an den Internet Explorer zurück. Damit kann es die Ausführung unerwünschter aktiver Inhalte zuverlässig unterbinden.

IEController bietet somit eine wesentlich flexiblere Verwaltung der sicherheitsrelevanten Funktionen als der Browser selbst. Man muss keine Alles-oder-nichts-Entscheidung mehr treffen (entweder alle ActiveX-Controls zulassen oder alle sperren), sondern kann beispielsweise Flash zulassen, während die Ausführung aller anderen Controls verhindert wird. Auch Microsofts JavaScript-Variante (JScript) lässt sich unabhängig von VBScript aktivieren (oder umgekehrt), wohingegen die Sicherheitseinstellungen des Internet Explorer beides unter ActiveScripting zusammenfassen.

Außerdem hält sich der Browser nicht so eng an die eingestellten Sicherheitsoptionen, wie man meinen könnte. Er lädt die ‘vbscript.dll’ für interne Zwecke, etwa beim Anzeigen der Eigenschaften einer Website - auch wenn ActiveScripting explizit abgeschaltet ist. Einmal im Speicher, könnte die DLL womöglich ein Sicherheitsloch für Angriffe von außen öffnen. Es ist daher besser, den Internet Explorer mit IEController zu kontrollieren, als sich auf seine eingebauten Sicherheitsmechanismen zu verlassen.

Der Internet Explorer erzeugt aber eine gewaltige Menge an COM-Objekten, auch wenn gar keine aktiven Inhalte geladen werden. Bis sich ein leeres Fenster geöffnet hat, erzeugt der Browser schon unzählige Objekte. Und wenn man das erste Zeichen in die Adresszeile eingibt, fährt er damit fort. IEController verwaltet deshalb Filterlisten mit Regeln, nach denen Objekte zugelassen werden oder nicht.

Massenhaft Objekte

Es gibt drei verschiedene Filterlisten: Eine mit fest vorgegebenen Einträgen, die man im Auswahldialog ein- und ausschalten kann, und zwei frei editierbare. Die vorgegebene Liste (Greylist) beginnt mit einem Eintrag, der die vom Browser für den normalen Betrieb benötigten Objekte zusammenfasst. Daneben enthält sie Vorgaben für JScript, VBScript, Java, Flash und den Acrobat Reader. Jeden dieser Punkte kann man sperren oder erlauben.

Im Expertenmodus lassen sich die beiden editierbaren Listen pflegen: Die Whitelist führt alle zugelassenen COM-Objekte auf. Für selten benötigte Objekte, von denen unter anderen Umständen Gefahr ausgeht, kann man hier die Option ‘Nur auf Nachfrage’ setzen. Die Blacklist führt alle verbotenen Objekte auf. Für Testzwecke lassen sich die Einträge in den beiden Listen deaktivieren.

IEController arbeitet die Filterlisten in einer festen Reihenfolge ab. Die Blacklist hat die höchste Priorität. Das stellt sicher, dass vom Anwender explizit verbotene Objekte auf keinen Fall ausgeführt werden. An zweiter Stelle rangiert die Greylist. Verbietet man hier VBScript, so lässt sich dies im Expertenmodus durch einen Eintrag in der Whitelist nicht überschreiben. Ein Eintrag in der Blacklist setzt hingegen eine Erlaubnis in der Greylist außer Kraft.

Alle COM-Objekte, die keine der drei Listen erfasst, gelten als unbekannt. Auf unbekannte Objekte reagiert IEController abhängig von seiner Konfiguration: Entweder lässt er sie zu (hohes Sicherheitsrisiko), verhindert ihren Start (sicher) oder er öffnet eine Dialogbox und überlässt die Entscheidung dem Anwender. Als Entscheidungshilfe nennt das Programm dabei den Namen, den der Programmierer dem Objekt gegeben hat, die Datei, die den Programmcode enthält (z. B. jscript.dll) sowie die CLSID. Diese Informationen lassen keine sicheren Rückschlüsse darauf zu, ob es sich um ein gutes oder böses Objekt handelt.

Schadstofffilter

In der Dialogbox kann man auswählen, ob die Entscheidung nur einmal gilt oder ob das Objekt generell erlaubt beziehungsweise gesperrt werden soll. Dadurch wird es in die White- beziehungsweise Blacklist übernommen. Außerdem lassen sich diese beiden Listen über eine Importfunktion befüllen. So stellt c't zu IEController Konfigurationsdateien bereit, um COM-Objekte zu sperren, die bei der Ausführung bekannter Exploits erzeugt werden. Man muss dann nicht mehr darauf warten, bis sich Microsoft eines Sicherheitsproblems annimmt (wenn überhaupt), sondern kann sofort Gegenmaßnahmen ergreifen. Alle Dateien zu diesem Projekt finden Sie unter dem Soft-Link zu diesem Artikel. Dort gibt es auch eine Online-Hilfe zu dem Tool.

Der Nutzen von IEController hängt von der Qualität der Filterlisten ab. Wir haben sorgfältig getestet, welche Objekte der Internet Explorer im normalen Betrieb benutzt, um die Standardliste möglichst komplett zu halten. Doch was ist der ‘normale’ Betrieb? Etwa zum Drucken der aktuellen Seite oder zum Aufruf des E-Mail-Clients beim Anklicken eines Mailto-Links benötigt der Browser spezielle Objekte. Gleiches gilt für so genannte Browser Helper Objects (BHO) wie die Google-Toolbar.

Es ist durchaus möglich, dass wir nicht jedes denkbare Anwendungsszenario erfasst haben. Sollte der Internet Explorer eine bestimmte Funktion nicht bieten, wenn er über den Loader gestartet wurde, können Sie die Konfiguration so ändern, dass bei unbekannten Objekten nachgefragt wird. Dann lässt sich ermitteln, welches Objekt die Funktion erfüllt und in der Whitelist eine Regel dafür anlegen. Bitte informieren Sie uns in einem solchen Fall durch eine E-Mail an iec@ct.heise.de.

Beim ersten Starten erlaubt die Greylist nur die für den Betrieb des Internet Explorer wichtigen Objekte; Java, JScript et cetera bleiben abgeschaltet. Die Black- und Whitelist sind leer; unbekannte Objekte werden gesperrt. Während Microsoft die Strategie verfolgt, im Internet Explorer alles zu erlauben, sodass der sicherheitsbewusste Anwender alle gefährlichen Optionen abschalten muss, verfolgen wir mit IEController einen anderen Ansatz: Zunächst ist alles verboten und was man benötigt, lässt sich einschalten.

Als zusätzliches Sicherheitsfeature fragt IEController beim Download einer Datei (z. B. xyz.zip) nach, ob das zugehörige Programm (z. B. WinZip) gestartet werden soll. Diese Abfrage lässt sich im Unterschied zu der des Internet Explorer nicht abstellen. Außerdem zeigt IEController dabei den Dateinamen der Applikation an, die gestartet werden soll.

Über das Konfigurationsmenü kann man mehrere Konfigurationen anlegen, die mit unterschiedlichen Optionen und Filterlisten arbeiten. So ist es möglich, ähnlich wie beim Zonenmodell des Internet Explorer, mit mehr oder weniger restriktiven Sicherheitseinstellungen zu surfen, abhängig davon, für wie vertrauenswürdig man die besuchten Sites hält. Für jede Konfiguration erzeugt das Programm ein neues Icon, über das man den Internet Explorer starten kann.

IEController benötigt Administratorrechte, damit es den Internet-Explorer-Prozess vor dem Starten patchen kann. Der Anwender muss sich also als Administrator anmelden oder den Loader über die rechte Maustaste über ‘Ausführen als’ starten und das Admin-Passwort eingeben. Das vom Loader gestartete Programm hat standardmäßig dieselben Rechte, also wird der Internet Explorer auch mit Administratorrechten gestartet. Das stellt jedoch bei den meisten Systemen keinen Nachteil dar.

Die Möglichkeiten des IEController sind noch längst nicht ausgeschöpft. Unter Berücksichtigung der Erfahrungen, die Anwender mit IEController sammeln, soll es eine Version 2.0 geben. Es sind noch etliche Erweiterungen denkbar, etwa die engere Einbindung ins Betriebssystem, damit der Internet Explorer nicht nur nach dem direkten Aufruf kontrolliert wird, sondern auch, wenn ihn andere Applikationen als Anzeigemodul verwenden.

Perspektiven

In einem späteren Artikel werden wir genauer auf die Programmierung des Tools eingehen und auch den Quelltext zur Verfügung stellen. IEController ist universeller, als der Name vermuten lässt: Mit entsprechend angepassten Filterlisten könnte der Loader auch andere Programme wie Outlook Express, Opera oder Mozilla kontrollieren.

Letztlich geht es uns hier auch um einen Proof-of-Concept. Die Grundfunktion des Programms, also die totale Kontrolle dessen, was der Internet Explorer tut, ließ sich relativ einfach implementieren. Man muss sich fragen, warum Microsoft nicht ähnliche Mechanismen zur Verfügung stellt. Die Programmierer des Internet Explorer haben einen wesentlich besseren Überblick über die Objekte, die ihr Browser nutzt. Sie müssten nicht über einen Loader gehen, sondern könnten die Verwaltung der Filterlisten in die Einstellungen des Browsers integrieren. Der Anwender wäre in der Lage, als unsicher bekannte Techniken abzustellen, ohne auf ein Zonenmodell angewiesen zu sein, bei dem er die Zuverlässigkeit von Website-Betreibern vorausahnen muss. (ad)

Literatur

[1] Matthias Withopf, Wachtmeister, Programme unter Windows 95/NT überwacht ausführen, c't 14/98, S. 200

(ad)