Diese Woche gab es eine bunte Mischung an Neuigkeiten und Schwachstellen, von denen ich einige näher betrachten möchte. Den Anfang macht Microsoft: Am Patchday wurden wie angekündigt 12 Security-Bulletins veröffentlicht (Übersicht auf englisch und deutsch). Die im Dezember und Januar entdeckten kritischen Lücken in Word (#1, #2, #3, #4) wurden geschlossen, außerdem zwei bisher unbekannte kritische Schwachstellen in Office, die ebenfalls durch präparierte Word-Dokumente die Ausführung beliebigen Codes erlauben. Auch die erst Anfang des Monats gefundene Lücke in Excel wurde bereits gestopft, ebenso eine seit Oktober offene Schwachstelle in der Funktion ADODB.Connection.Execute() der Data Access Components.

Die restlichen gestopften Schwachstellen waren bisher nicht öffentlich bekannt. Als kritisch wurden von Microsoft Schwachstellen im Step-by-Step Interactive Training und im HTML Help ActiveX Control eingestuft. Auch im Internet Explorer wurden drei kritische Schwachstellen behoben. Alle diese Schwachstellen erlauben die Ausführung beliebigen Codes aus der Ferne. Die in meinen Augen diesmal gefährlichste ist die von Microsoft ebenfalls als kritisch eingestufte Schwachstelle in der Malware Protection Engine: Beim Parsen präparierter PDF-Dateien kommt es zu einem Integerüberlauf, der die Ausführung beliebigen Codes erlaubt. Betroffen sind alle Sicherheitsprodukte (Live OneCare, Antigen, Defender und ForeFront). Das Gefährliche daran ist, dass die Schwachstelle ohne Interaktion des Benutzers ausgenutzt werden kann, indem einfach eine Mail mit einer präparieren PDF-Datei an das Opfer geschickt wird. Während das Opfer sich darauf verlässt, dass sein Schutzprogramm Schädlinge herausfiltert, führt dieses gerade im Hintergrund den eingeschleusten Code aus. Allerdings ist dies kein Microsoft-spezifisches Problem, derartige Schwachstellen sind in allen Schutzprogrammen extrem unangenehm.

Wichtig nimmt Microsoft eine Schwachstelle bei der Erkennung neuer Hardware und im 'Windows Image Acquisition Service', die beide von lokalen Benutzern zur Ausweitung ihrer Rechte ausgenutzt werden konnten. Außerdem wurden drei wichtige Schwachstellen im Zusammenhang mit OLE-Objekten behoben: In der OLE-Dialog-Komponente, der MFC-Komponente (auch in Visual Studio .NET) und der RichEdit-Komponente. Letztere betrifft auch Office. Alle drei erlauben die Ausführung beliebigen Codes, erfordern aber mehr oder weniger intensive Mitarbeit der Benutzer.

Nach dem Patchday ist vor dem Patchday...
Damit sah die Übersicht des Internet Storm Centers über fehlende Microsoft-Patches am Mittwoch Morgen sehr viel erfreulicher aus als noch am Montag. Leider blieb es dabei nicht lange: Schon am Mittwoch/Donnerstag wurde über eine neue Word-Schwachstelle berichtet, die die Ausführung von Code erlaubt und bereits für gezielte Angriffe genutzt wurde. Allerdings ist diese Schwachstelle nicht ganz so neu, da bereits am 9. Februar im Blog der McAfee Avert Labs darüber berichtet wurde. Das ist anscheinend nur niemandem aufgefallen, bis es auch in Microsofts Security Response Center Blog veröffentlicht wurde. Außerdem wurde eine Denial-of-Service-Schwachstelle in Excel gefunden. Vielleicht sollten wir analog zum Patchday am zweiten Dienstag jedes Monats den folgenden Mittwoch oder Donnerstag zum Microsoft-0-Day-Day ernennen, genutzt wird er sowieso schon so.

Einmal kräftig rückwärts rudern...
Und noch einmal Microsoft: Mark Russinovich hat in einem Blog-Beitrag die Grenzen der User Account Control (UAC) aufgezeigt: "It should be clear then, that neither UAC elevations nor Protected Mode IE define new Windows security boundaries. Microsoft has been communicating this but I want to make sure that the point is clearly heard." Also zumindest ich hatte das bisher anders verstanden und auch entsprechend als Argument für Vista aufgefasst. Und etwas später kommt es dann gleich ganz dicke: "Because elevations and ILs don't define a security boundary, potential avenues of attack, regardless of ease or scope, are not security bugs." Nachtigall, ick hör' dir trapsen: Hat da etwa jemand einen Weg gefunden, die neuen Sicherheitsfunktionen zu umgehen, und um einer Blamage aus dem Weg zu gehen, wird die Sicherheitsfunktion flugs zu einer Nicht-Sicherheitsfunktion umdefiniert? Joanna Rutkowska fand es zumindest zum Lachen: Vista Security Model - A Big Joke? (Bitte auch/zumindest die Klarstellung von ihr dazu lesen: Confiusion (sic) About The "Joke Post")."It's not a bug, it's a feature!" kenne ich ja schon aus Atari-Zeiten, aber "It's no feature, so it's not a bug" ist mal was Neues.

Im Vorbeifahren ein paar DNS-Einträge fälschen...
In einer Mail auf der Mailing-Liste Full-disclosure ("Drive-by Pharming") und in einem Blog-Eintrag von Symantec ("Drive-By Pharming: How Clicking on a Link Can Cost You Dearly") wird vor einer neuen Gefahr für unzureichend gesicherte Router gewarnt: Durch Manipulation der DNS-Server-Adressen kann ein Angreifer den gesamten Internetverkehr des Opfer-Routers zu sich umleiten und vertrauliche Daten ausspähen oder gefälschte Daten einschleusen. Symantec hat auch eine Flash-basierte Animation dieser Angriffsweise erstellt. Die Warnung basiert auf einer Arbeit von Sid Stamm, Zulfikar Ramzan und Markus Jakobsson ("Drive-By Pharming", PDF). Sie zeigen, wie über eine präparierte Webseite mit einer Kombination von Java-Applets und JavaScript der Router eines Netzes aufgespürt, das Modell identifiziert und danach bei einer ungeschützten (bzw. nur mit dem Default-Passwort geschützten) Weboberfläche der Eintrag für den DNS-Server geändert werden kann. Der geänderte DNS-Server-Eintrag wird vom Router dann per DHCP im lokalen Netz verbreitet. Zu Gute kommt dem Angreifer dabei, dass oft die Default-Passwörter nicht geändert werden. Der Einsatz von JavaScript für ähnliche Angriffe war ja bereits Thema in den 'Standpunk Sicherheit'-Texten vom 14. August und 23. Oktober 2006.

Außer der Änderung der Default-Passwörter schlagen die Autoren als Gegenmaßnahme auch vor, dass die ISPs DNS-Verkehr herausfiltern, der nicht an die eigenen DNS-Server gerichtet ist. Das mag eine nahliegende Lösung sein, die ich aber aus zwei Gründen nicht mag: Zum einen habe ich wie auch sicher viele andere gelegentlich mit DNS-Problemen zu kämpfen. Dann ist es äußerst nützlich, außer den DNS-Servern des eigenen ISPs noch mindestens einen unabhängigen zur Verfügung zu haben. Zum anderen erleichtert es mögliche Zensurmaßnahmen durch DNS-Manipulationen. Wer weiß, wann mal wieder eine Bezirksregierung über die Stränge schlägt und mit der DNS-Sperrungs-Kanone auf Website-Spatzen schießt? Und ich möchte dann schon noch gerne auf nicht.verboten.example zugreifen können, wenn ist.verboten.example gesperrt werden soll und die ISPs verboten.example komplett blockieren.

Carsten Eilers