Diese Woche im "Standpunkt Sicherheit": Eine wenig aussagekräftige Studie über die Verbreitung von Webbrowsern, ein Security-Advisory für einen nicht sicherheitsrelevanten Vorfall und ein Ausblick auf den kommenden Patchday von Microsoft.
Studie mit fragwürdigen Daten
An der ETH Zürich ist eine Studie mit dem schönen Titel 'Understanding the Web browser threat: Examination of vulnerable online Web browser populations and the "insecurity iceberg"' erschienen. Kernaussage dieser - in meinen Augen wenig aussagekräftigen - Studie: Die meisten Webnutzer sind mit veralteten und damit unsicheren Browsern unterwegs. Angeblich.
Angeblich? Angeblich!
Wieso ich die Studie für wenig aussagekräftig halte, ist schnell erklärt: Für die Ermittlung der verwendeten Browser wurden Webserver-Statistiken von Google verwendet, und darin die verwendeten Browser über den User-Agent-Header identifiziert. Was ist das Erste, was man im Bereich Sicherheit jedem einbläut? Richtig: Traue nie dem Client. Einer Studie, die sich auf diese Angaben stützt, kann ich also schon aus Prinzip nicht trauen. Selbst wenn man davon ausgeht, dass die meisten Benutzer den User-Agent-Header nicht absichtlich ändern, sagt der in meinen Augen nicht besonders viel aus. Denn die Änderung kann auch über einen Proxy vorgenommen werden, der diese Informationen z.B. aus Datenschutzgründen löscht oder verfälscht. Viel schwerer wiegen aber zwei weitere Kritikpunkte: Wie auch von Robert Hensing und David LeBlanc festgestellt wurde, gibt der Internet Explorer als User-Agent nur die Hauptversion und nicht den Patchstand preis. Daher wurden in der Studie für den IE die Daten von Secunias Personal Software Inspector herangezogen. Zwar wurden da nicht direkt Äpfel mit Birnen verglichen, aber doch zwei unabhängige Datenbestände vermischt, die nicht sehr viel miteinander zu tun haben. Hinzu kommt, dass ein voll gepachter IE 6 genauso sicher ist wie ein aktueller IE 7, im Rahmen der Studie aber als unsicher eingestuft wurde. Und ob unsichere Plug-ins installiert sind, wurde sowieso nur geraten. Aha. Na, da hätte man sich das Ganze auch sparen können.
Außer Spesen nichts gewesen?
Auf jedem Fall kann die Studie bekanntlich noch als schlechtes Beispiel dienen. Aber das ist nicht nötig. Auch aus verfälschten Daten kann man nützliche Schlüsse ziehen: Die bisherigen Schutzmaßnahmen müssen verbessert werden. Die Idee eines 'Verfalldatums' ist dabei in meinen Augen nur mit wenig schmeichelhaften Wörtern zu kommentieren, also lasse ich das. Wer soll das Verfalldatum prüfen? Die Webserver-Betreiber, ISPs usw. können dafür nur den User-Agent-Header oder andere vom Benutzer gelieferte Informationen verwenden. 'Vertraue nie dem Client' - also, vergessen wir die Idee ganz schnell. Würde so etwas implementiert, wäre der erste Schritt jeder Schadsoftware die Anpassung der entsprechenden Informationen und damit das Unterlaufen dieser Prüffunktionen.
Verfalldatum im Browser?
Bleibt noch die Möglichkeit, das Verfalldatum im Programm zu implementieren. Variante 1: Das Verfalldatum wird hart implementiert und das Programm verweigert nach einem bestimmten Datum den Betrieb. Sicherer geht es wohl kaum. Aber erstens würde kein Mensch so ein Programm kaufen, zweitens gäbe es ganz schnell Hacks, um diese Funktion zu umgehen. Variante 2: Der Benutzer wird darauf hingewiesen, dass das Programm veraltet ist. Na und? Who cares? Ich habe hier auch noch einen Rechner mit Mac OS X 10.3 stehen, und darauf läuft per Default eine entsprechend alte Version von Safari: 1.3.2. Aktuell ist 3.x, die gibt es aber nur für Mac OS X 10.4 und 10.5. Bei Windows-Systemen sieht es ähnlich aus. Ein Verfalldatum würde also auf einen Wechsel des Betriebssystems oder des Browsers hinauslaufen. Und jetzt überlegen wir einmal, wie es in Unternehmen aussieht: Da gibt es oft sehr strikte Regeln für die eingesetzten Betriebssysteme und Programme. Den Versuch, da einen System- oder auch nur Browserwechsel durchzusetzen, möchte ich nicht erleben. Da kann das Programm noch so sehr quengeln. Am Ende würde es vielleicht dazu führen, dass es ersetzt wird - dann aber gegen ein unbegrenzt Einsetzbares.
Und nun?
Das Problem der unsicheren Plug-ins löst das Browser-Verfalldatum sowieso nicht. Über das Ganze muss man also noch einmal gründlich nachdenken. Natürlich ist die Idee eines Browser-TÜVs reizvoll, nur: Wie sollte das funktionieren? Einigen Politikern würden sicher regelmäßige Kontrollen durch eine Behörde, die bei der Gelegenheit auch gleich den Bundestrojaner aktualisiert, gefallen. Aber realistisch betrachtet bleibt nur, die vorhandenen Möglichkeiten wie automatisierte Updates etc. zu optimieren. Und da die Studie eigentlich gar nichts darüber aussagt, welche Browser nun wirklich in einer sicheren oder unsicheren Version eingesetzt werden, kann sie dafür nicht mal hilfreiche Hinweise geben. Schade. Denn wie schon kritisiert, werden Google- und Secunia-Daten vermischt, um Aussagen über Firefox, Opera und Safari einerseits und IE andererseits treffen zu können, und der weit verbreitete IE 6 wird unabhängig vom Patchstand als unsicher eingestuft. So wird das nichts. Leider.
Security-Advisory, aber 'non-security issue'
Auch das gibt es: Ein Security-Advisory für etwas, das keinen Sicherheitsbezug hat. Wo? Natürlich bei... Microsoft: 'Microsoft Security Advisory (954960): Microsoft Windows Server Update Services (WSUS) Blocked from Deploying Security Updates'. Das fängt mit 'Microsoft is investigating public reports of a non-security issue that prevents the distribution of any updates ...' Also das Nicht-Verteilen von Updates, einschließlich sicherheitsrelevanter Patches, würde ich nicht gerade als 'non-security issue' bezeichnen. Natürlich ist so etwas peinlich, aber Probleme mit Updates gab es bei Microsoft ja nun schon öfter, auf eines mehr oder weniger kommt es da auch nicht mehr an. Und immerhin ist es mal etwas Neues: Sonst wurden immer Updates ohne Zustimmung des Benutzers installiert, jetzt werden sie trotz seiner Zustimmung nicht installiert.
Worum geht es diesmal? Versucht ein Windows Server Update Services (WSUS) Version 3.0 und 3.0 SP1, ein Update auf einen System zu installieren, auf dem Microsoft Office 2003 installiert ist, gibt es nur eine Fehlermeldung und das Update wird nicht installiert. Da das auch die Patches der Security-Bulletins betrifft, sollte jeder, der den WSUS und Office 2003 in seinem Netz einsetzt, den vorgeschlagenen Workaround in Betracht ziehen. Sonst gilt für die am Dienstag fälligen Juli-Patches 'Wir müssen leider draußen bleiben' - auch, wenn man sie eigentlich rein lassen will.
Patchday ohne kritische Patches
Für den Juli-Patchday hat Microsoft 4 Security-Bulletins angekündigt, die allesamt nur als 'wichtig' eingestuft werden. Das 'SQL Bulletin' betrifft eine Privilegieneskalation in Windows und dem SQL-Server, das 'Exchange Server Bulletin' eine im Exchange Server. Das 'Windows Bulletin 1' betrifft die Ausführung beliebigen Codes aus der Ferne in Windows. Da es nicht als kritisch eingestuft wurde, ist dafür vermutlich eine Aktion eines Benutzers und/oder eine ungewöhnliche Konfiguration notwendig. Könnte sich darüber ein Wurm verbreiten, d.h. wäre die Codeausführung ohne Benutzeraktion möglich, wäre die Einstufung laut 'Microsoft Security Response Center Security Bulletin Severity Rating System' 'kritisch'. Das letzte Bulletin heißt vorerst 'Windows Bulletin 2' und wird eine Spoofing-Schwachstelle in Windows beschreiben. Spoofing - da fällt mir spontan die Spoofing-Schwachstelle im DNS-Client ein, die mit dem Patch zum Bulletin MS08-020 eigentlich behoben werden sollte. Der Patch war ja anscheinend fehlerhaft, und von einer Korrektur ist mir nichts bekannt. Na, mal sehen, was da alles kommt. Dienstag wissen wir mehr.
Carsten Eilers
