In der letzten Woche war ja einiges los, über das sich zu schreiben lohnt. Da fällt die Auswahl schwer. Anfangen will ich mit einer Schwachstelle, die es eigentlich gar nicht geben dürfte. Dass Cross-Site-Scripting-Angriffe auch über andere als die üblichen Wege ausgeführt werden können, hatte ich schon im Standpunkt Sicherheit vom 18. September 2006 erwähnt. Petko D. Petkov, auch bekannt als pdp (architect), hat seine damals erwähnten Beispiele verfeinert und dadurch eine größere Lücke als die damals angenommene aufgedeckt: In Multimedia-Dateien enthaltener JavaScript-Code wird beim Abspielen in QuickTime im Standard-Browser ausgeführt, und das im Fall von Firefox auch noch in der Chrome-Umgebung, d.h. mit den höchstmöglichen Rechten. Betroffen sind QuickTime-Link-Dateien (.qtl), XML-Dateien, die normalerweise einen Link auf die eigentliche Mediendatei und ggf. weitere Steuerungsanweisungen für den QuickTime-Player enthalten. QuickTime führt diese Anweisungen auch aus, wenn die Datei eine andere, dem QuickTime-Player oder -Plug-in zugewiesene Endung einer Audio- oder Videodatei wie z.B. .mov oder .mp3 besitzt.

Der Angreifer kann dadurch erst einmal nur beliebigen JavaScript-Code im Default-Webbrowser ausführen. In Firefox auch in der privilegierten Chrome-Umgebung, und dann wird es gefährlich. Denn das heißt, er kann machen, was er will, z.B. eine Hintertür als Erweiterung installieren. Arbeitet das Opfer mit Administrator-Rechten ist auch der Zugriff auf beliebige Betriebssystemfunktionen möglich.

Besonders pikant dabei: Eigentlich sollten die Beispiel-Exploits nicht funktionieren. Mit QuickTime 7.1.5 wurden die Schwachstellen mit den CVE-IDs CVE-2006-4965 und CVE-2007-0059 behoben - gerade die von pdp (architect) ursprünglich gefundenen Schwachstellen.

Die Beschreibung des Fix durch Apple:
Description: A cross-zone scripting issue exists in QuickTime's browser plugin. By enticing a user to open a malicious QuickTime movie file or QTL file, an attacker can trigger the issue, which may lead to arbitrary JavaScript code execution in context of the local domain. This issue has been described on the Month of Apple Bugs web site (MOAB-03-01-2007). This update addresses the issue by making the following changes to the handling of URLs in the qtnext attribute of QTL files, and HREFTracks in QuickTime movies. Only "http:" and "https:" URLs are allowed if the movie is loaded from a remote site. Only "file:" URLs are allowed if the movie is loaded locally.

Einer der qtnext-Einträge aus den Beispiel-Exploits von pdp (architect), die alle denselben Aufbau haben:

qtnext="-chrome javascript:file=Components.classes[..."

Also das ist eindeutig keine "http:"-, "https:"- oder "file:"-URL. Da scheint jemand seine Hausaufgaben nicht gemacht zu haben. Eine Teilschuld kann man den Browser-Herstellern geben, die sollten auch besser aufpassen, womit sie aufgerufen werden. Aber die Ursache liegt eindeutig bei Apple: Solche URLs dürften nicht übergeben werden.

Ach so: Prinzipiell funktionieren die Exploits auch auf dem Mac. Jedenfalls insofern, dass der Standard-Browser aufgerufen und ihm die Kommandozeile übergeben wird. Danach ist dann Schluss, da die angegebenen Pfade und .exe-Dateien nicht existieren. Aber das kann man ja anpassen...

Microsoft lernt es wohl nie ...
... wie man mit seinen Kunden besser nicht umgeht. Jedenfalls hat da jetzt wieder irgendjemand kräftig Anlauf genommen und ist dann genau ins Fettnäpfchen gehüpft. Oder kurz gesagt: Microsoft spielt bestimmte Updates auch dann ein, wenn Benutzer nur nach Updates suchen lassen und darüber informiert werden möchten. Microsofts Manager für Windows Update, Nate Clinton, hat in einem Eintrag im Microsoft Update Product Team Blog dazu Stellung genommen: Updates für den Windows-Update-Client von Windows XP und Vista wurden auch gegen den Willen der Benutzer installiert, da die alten Versionen neue Updates nicht mehr gefunden hätten. Man hat den Update-Mechanismus also so geändert, dass ein Update des Updaters notwendig war. Ich nehme an, dafür hatte man gute Gründe.

Aber welchen Grund kann es geben, dieses Update zwangsweise und ohne Zustimmung des Benutzers durchzuführen? Denn wenn die automatische Suche nach Updates aktiv ist, wurde dieses Update eingespielt - ohne den Anwender zu fragen. Unabhängig davon, ob Patches automatisch installiert werden sollen oder der Benutzer nur informiert werden möchte. Das ist eine Unverschämtheit, um es mal moderat auszudrücken. Besonders nett finde ich die Unterscheidung, wer das Zwangsupdate bekommt, und wer nicht: Endbenutzer und kleine Unternehmen ("consumer and small business customers (customers without an IT staff)") bekommen das Update zwangsweise installiert. In lokalen Netzen, die die Updates über den Windows Server Update Services (WSUS) oder Systems Management Server (SMS) verteilen, haben die Administratoren die Kontrolle über alle Updates, auch über das für den Windows-Update-Client. Also entweder, ich muss für meinen einen Windows XP-Rechner hier im Büro jetzt WSUS oder SMS installieren, oder mir gefallen lassen, dass Microsoft bestimmt, was auf dem Rechner installiert wird? Genauso bei meinen Kunden, die durchaus in der Lage sind, ihre Systeme selbst zu administrieren bzw. jemanden haben, der das kann, die aber WSUS oder SMS nicht brauchen? Und wie sieht das eigentlich aus, wenn beim Update mal was schiefgeht? Das wäre ja nicht das erste Mal. Aber vielleicht möchte Microsoft ja nur die geänderten Paragraphen im StGB testen.

Also, ich sehe ja ein, dass dieses Update notwendig ist. Und wenn man mich darum gebeten hätte, hätte ich es auch installiert. Aber das ist noch lange kein Grund und erst recht keine Rechtfertigung dafür, es heimlich zu tun. Halten die sich für Schäuble oder was ist in die Verantwortlichen gefahren? Gibt es dann demnächst so den Bundestrojaner? Das ist jetzt (hoffentlich) etwas überzogen, aber Vertrauen gewinnt man so nicht, ganz im Gegenteil.

Ach ja: "In fact, WU has auto-updated itself many times in the past." Und was hat sich sonst noch alles automatisch aktualisiert?

Olle Kamellen bei Aldi?
Das letzte Woche von Aldi verkaufte Medion-Notebook MD96290 wurde laut Berichten in verschiedenen Foren, z.B. dem von Avira, anscheinend ab Werk mit dem Bootsektor-Virus Stoned.Angelina (siehe z.B. bei Symantec) ausgeliefert. Die Medion AG hat erklärt, dass das Notebook nicht mit dem Virus ausgeliefert worden ist. Viel interessanter als die Schuldfrage finde ich die Frage: Wie kommt ein DOS(!)-Bootsektorvirus auf die Festplatte eines aktuellen Notebooks? Der Virus ist von 1994 - der dürfte in der freien Wildbahn inzwischen an Nahrungsmangel ausgestorben sein. Die einzige Erklärung, die mir einfällt: Irgendwo steht noch ein alter DOS-Rechner, der z.B. für die Prüfung der Festplatten oder Notebooks verwendet wurde und die dabei infiziert hat. Etwas ähnliches ist Apple letztes Jahr bei einigen Video-iPods passiert, die mit einem (allerdings aktuellen) Windows-Wurm ausgeliefert wurden. Und damit wäre dann doch Medion bzw. ein Zulieferer der Verursacher. Das sollte besser geklärt werden, bevor so noch mehr Viren verbreitet werden. Womöglich irgendwann auch noch aktuelle, die wirklich Schaden anrichten können.

Carsten Eilers