Die Sicherheitsprobleme des Internet Explorers sind architekturbedingt

Die Ursache des Dilemmas "Internet Explorer" rührt daher, dass der Internet Explorer (IE) (wie im Grunde alle Microsoft-Programme) tief im System verankert ist und dabei (und das ist der Kern des Problems) nicht in sich abgegrenzt ist, sondern auf viele Systemmerkmale und -komponenten rund um sich herum angewiesen (sprich: abhängig) ist. Das macht es letztlich auch so schwer, den IE aus dem System zu entfernen.

Wir stellen also fest: eine Applikation, die Daten (HTML, aktive Inhalte usw.) aus zunächst mal grundsätzlich als unsicher zu bezeichnenden Quellen (Internet) auf dem PC anzeigt und sogar ausführt, ist tief im System verwurzelt, statt als Add-on im wahrsten Sinne des Wortes "on top" des Betriebssystems zu laufen.
Das alleine ist das erste eklatante Architekturmerkmal, warum der IE im Kerne potenziell unsicherer sein muss, als eine on top-Applikation wie bspw. der Mozilla-Browser.

Dazu paart sich ein eklatanter Verstoß gegen das Prinzip der Komplexitätsreduktion durch Minimalismus bzw. Vereinfachung und Einfachheit: Windows mit dem IE ist zunächst mal alles andere als modular aufgebaut. Im Gegenteil, es ist intern weitgehend abhängig von einander integriert. So kann der IE ohne Windows nicht existieren (Ausnahme Mac: dort gibt es auf Grund der andersartigen Architektur des IE diese Tiefenverwurzelung nicht wie auf Windows und infolgedessen auch teils ganz andere Sicherheitsprobleme als unter Windows).

Bei Unix, BSD, Linux usw. findet man eine Architektur des Minimalismus. Diese unixoiden Systeme sind durch kleine, in sich abgegrenzte Komponenten und Programme geringer Komplexität gekennzeichnet. Sie sind in sich einfach und abgeschlossen und sind mit vergleichsweise vertretbarem Aufwand überprüfbar. Es gibt wenige bis gar keine Abhängigkeiten von anderen Komponenten. Dadurch wird die Komplexität jedes Teils in sich relativ gering gehalten. Komplexität lässt sich hier dadurch herstellen, in dem man beliebig viele kleine wenig bis unkomplexe Programme zu großen komplexen Werkzeugen zusammenstellt. In sich bleiben die Bestandteile des komplexen Systems aber weiterhin abgegrenzt und gering komplex. Somit ist es auch vergleichsweise einfach, Fehler und Sicherheitslücken in diesen abgegrenzten Modulen zu schließen. Nur das betroffene Objekt wird verändert. Selten hat dieses funktionale Auswirkungen auf seine Repräsentierung gegenüber anderen Modulen. Dadurch bleibt das System vergleichweise einfach und überschaubar.

Demgegenüber ist Windows nicht modular aus kleinen unkomplexen Komponenten zusammengebaut sondern ein in sich komplexes und monolithisch wirkendes Gebilde. Die Komplexität ist Windows innewohnend. Durch die Abhängigkeiten der zahlreichen Komponenten untereinander ist es demgemäß ausgesprochen schwierig, Veränderungen an Teilen des Systems vorzunehmen, da sich Änderungen unmittelbar durch die Abhängigkeiten im Gesamtsystem auswirken.

Das erklärt, warum Microsoft

1. sehr oft sehr viel Zeit benötigt, bis ein Patch erscheint
2. ein Patch (s.h. bspw. Auswirkung des SQL-Slammer-Patches auf den SQL-Server 2000) oftmals erhebliche Seiteneffekte hervorruft (im vorgenannten Fall bis zum "gestorbenen" Server, der bei jedem Boot-Vorgang mit dem "Blue Screen of Death") abstürzt
3. ein Patch die Sicherheitslücke(n) oftmals nicht vollständig abdeckt bzw. andere Systemteile in Mitleidenschaft zieht.

Ein Patch in einem unixoiden System ist immer das Flicken eines Bugs in einer der vielen geringkomplexen Objekten bzw. Komponenten des Systems. Ein Bugfix oder Securitypatch ist hier i.d.R. passgenau. Bei Windows verhält es sich tatsächlich anders, da das Anfassen und Ändern einer Sache sehr oft einen Baum von Abhängigkeiten nach sich zieht, die (um das Gesamtsystem integer zu halten) ebenfalls alle angeglichen werden müssen. Dadurch kann es passieren, das ein Patch eben nicht nur Dinge im IE fixt sondern im Umfeld des IE einige system-interne Dinge umstellt bzw. durch andere Programmteile ersetzt, damit das Konglomerat an Abhängigkeiten auch nach dem Fixen des Sicherheitsloches konsistent bleibt.

Dies ist der Grund, warum die Probleme des Internet Explorers architektur-bedingt sind und nicht einfach durch Patchen des IE als solches gelöst werden können.

In Folge dieses Umstandes erleben wir hier den Beginn des Endes der Wartbarkeit von Windows. Irgendwann sind soviele Balkone und Dinge an Windows angeflickt, dass es wirtschaftlich bzw. technisch nachvollziehbar nicht mehr sinnvoll wartbar sein wird. Die ohnehin bereits oft langen Zyklen, in denen ein Patch für ein bestimmtes Problem erscheint, werden sich verlängern und die Qualität der Änderungen wir demgemäß zusehends schlechter werden (müssen).

Es ist sachlich festzuhalten, dass unixoide Systeme (so alt ihre Architektur auch sein mag) im Gegensatz zu Windows schon sehr sehr lange in der Liga stabiler Betriebssysteme für business-kritischste Anwendungen mitspielen. Vieles musste dort auf Grund von Sicherheitslöchern gefixt werden, aber diese Systeme sind dank ihrem modularem Aufbau und minimalistischer Komplexität sowie abgegrenzten Abhängigkeiten immer noch die, in denen Probleme am schnellsten und nachhaltigsten gelöst werden, wie die Praxis zeigt.

Ansgar H. Licher