CE.NET fast fertig

Bemerkenswert: Zum ersten Mal seit Beginn dieser Reihe vor einem guten halben Jahr gibt es diesen Monat keine neuen Sicherheitslöcher in Microsoft-Produkten zu beklagen und keine Patches anzukündigen - zumindest bis zum Redaktionsschluss dieser Ausgabe, der heuer recht früh lag.

Über die Gründe für diese ungewohnte Ruhe vermag man nur spekulieren: Ist etwa das letzte verbliebene Speicherleck abgedichtet und der letzte DoS-Angriffspunkt erfolgreich entschärft worden? Oder bummelt die überarbeitete IT-Welt gerade den Resturlaub von letztem Jahr ab und lässt die Beine in angenehm temperierten Karibikwellen und die Seele sonstwo baumeln? Vieles spricht für die zweite These, ist doch die Anzahl der neu bekannt gewordenen Sicherheitsschwachstellen in verschiedenen Unix-Systemen im selben Zeitraum ebenfalls stark gesunken.

In diese himmlische Ruhe hinein gellt der publizistische Schrei, dass der erste .NET-Virus auf den Plan getreten sei und dass Microsoft - man habe es ja schon immer gesagt - nicht in der Lage sei, einigermaßen sichere Software herzustellen. Wir wollen an dieser Stelle der Meute, die solches behauptet, nicht mit wehenden Druckfahnen hinterherrennen, sondern die Situation etwas differenzierter betrachten.

Zunächst ist es wichtig, zwischen .NET und .NET zu unterscheiden. Beim einen handelt es sich um einen Namenszusatz, den die Redmonder, genauer deren Marketing-Abteilung an jedes ihrer neuen Serverprodukte anhängen. So heißt der Nachfolger des Windows 2000 Server eben .NET Server. Das zweite .NET bezeichnet hingegen ein Software Engineering Framework, das Schlagwörter wie C# und Intermediate Language (MSIL) beinhaltet. Natürlich besteht eine Verbindung zwischen beiden: Produkte wie .NET Server oder Windows XP stellen die Umgebung zur Verfügung, die zum Ausführen von C#-Programmen benötigt wird.

Ebendiese Programme sind das Ziel des bewussten Virus names W32.Donut. Die Auswahl der Opfer erfolgt auf herkömmliche Art und Weise: Der Virus untersucht potenzielle Kandidaten daraufhin, ob es sich um MSIL-Programme handelt und infiziert sie gegebenenfalls. Wird ein infiziertes Programm ausgeführt, verbreitet sich der Virus weiter. Außerdem meldet sich W32.Donut mit einer Wahrscheinlichkeit von 10 Prozent bei jeder Ausführung mittels einer Dialogbox zu Wort und macht damit auf sich aufmerksam. Schadensroutinen sind keine vorhanden.

So etwas als .NET-Virus zu bezeichnen, ist etwas gewagt. Würde der Virus wie auch immer geartete .NET-Infrastrukturdienste zur Verbreitung verwenden, sähe die Sache anders aus. So aber ist W32.Donut einfach ein weiterer Virus, der einen bestimmten Dateityp befällt. Neu ist natürlich, dass es sich um MSIL-EXE-Dateien handelt; folglich wäre der Bösewicht besser ‘MSIL-Virus’ zu nennen. Leider klingt das nicht gut, und für eine Überschrift taugt es auch nicht.

John Montgomery, Product Manager bei Microsoft, bezeichnet W32.Donut treffend als ‘unwichtig’ und ‘ohne Bezug zu den (.NET) Web Services’. Es handele sich dabei um einen alten Windows-Virus, der dahingehend verändert worden ist, dass er MSIL-Dateien angreift. Der Dateityp aber habe nichts mit XML Web Services oder .NET als Ganzem zu tun. Und die Gartner Group erteilt dem ganzen die Absolution, indem sie darauf hinweist, dass .NET noch gar nicht vollständig verfügbar sei und somit überhaupt nichts vorhanden sei, dessen Sicherheit man kompromittieren könne.

Damit sei diese Geschichte ad acta gelegt und noch ein kurzer Blick auf den Internet Explorer geworfen. Hier sind einige kleinere Probleme bekannt geworden, und der einleitende Satz mag vor diesem Hintergrund vielleicht als etwas zu optimistisch erscheinen. Tatsächlich dürfte sich die Gefährdung von Benutzer oder Maschine aber im Rahmen halten, und so wurde keine der im folgenden geschilderten Schwachstellen von Microsoft offiziell bestätigt.

Das Objektmodell des Internet Explorer erlaubt es, auf den Inhalt der Zwischenablage per Skript zuzugreifen. Dieser Zugriff erfolgt ohne Warnung an den Benutzer, sodass es möglich ist, den Clipboard-Inhalt unbemerkt an beliebige Adressen zu verschicken. Weitere Details und eine Demo finden sich hier.

Ebenfalls mit einfachem Scripting kann jede beliebige Webseite die benutzereindeutige ID des Windows Media Player auslesen. Auf diese Art lassen sich Site-übergreifende Benutzungsprofile erstellen, ohne dass der Benutzer es je merken würde. Wer allerdings dem Ratschlag gefolgt ist, der im letzten Heft an dieser Stelle erschien, und dem Internet Explorer das Ausführen von ActiveX-Controls verboten hat, auch wenn sie als ‘safe for scripting’ markiert sind, ist wirksam vor diesem Problem geschützt. Weitere Informationen gibt es hier.

Schließlich demonstriert www.osioniusx.com, wie lokale Anwendungen durch Klick auf einen Link gestartet werden können. Hierbei handelt es sich natürlich um eine potenziell gefährliche Verhaltensweise des IE, obwohl es bisher nicht gelungen ist, den lokalen Anwendungen Parameter mitzugeben. Das Abschalten von Active Scripting führt hier zu einer - wenn auch nicht befriedigenden und hoffentlich nur temporären - Lösung.

Näheres zu den einzelnen Sicherheitsproblemen gibt es online. Die angegebenen KnowledgeBase-Artikel sind unter search.support.microsoft.com/kb erhältlich. Über die iX-Webseite sind alle bisherigen Ausgaben von Windows Security zu erreichen. (wm)