Kernel-Analyse

In der Februar-Ausgabe berichtete iX an dieser Stelle von einem Fehler im ActiveX-Control Microsoft.XMLHTTP, den der Marktführer zusammen mit dem IE 6 ausliefert. Dieser Fehler ermöglicht es, lokale Dateien ahnungsloser Websurfer auszulesen und an böswillige Webserver (oder deren Betreiber) zu verschicken. Damals gab es keinen Patch dafür; mittlerweile hat Microsoft nachgebessert und einen virtuellen Flicken bereitgestellt (Q317244).

Einen Patch gibt es glücklicherweise auch für eine weitere Schwachstelle im IE, die ähnlich schwerwiegend ist. Das Problem ist hier die Art und Weise, wie der Browser clientseitige VB-Skripte behandelt, die in einer Webseite ablaufen, die wiederum in einem Frame im IE dargestellt wird. Solche Skripte sollten eigentlich nicht in der Lage sein, auf andere Frames zuzugreifen, wenn deren Inhalt von anderen Web-Sites stammt. Leider tun sie das doch, und somit sind der Phantasie eines Datendiebes Tür und Tor geöffnet. Grundsätzlich ist es aufgrund dieses Sicherheitslochs möglich, jeden Besucher der eigenen Website auf seiner weiteren Surf-Session zu begleiten und alle Daten mitzulesen und folglich auch mitzuschneiden, die jener beispielsweise an seinen E-Mail-Provider oder seine Bank übermittelt. Wer sich davor schützen möchte, installiert den entsprechenden Patch oder lässt Active Scripting gleich abgeschaltet (Q318089).

Diese beiden Hotfixes sind übrigens nicht im neuen ‘Cumulative Patch’ für den IE enthalten, den Microsoft am 11. Februar veröffentlicht hat. Dieser Sammelpatch flickt einen ganzen Katalog undichter Stellen im Redmonder Webbrowser, von denen die meisten als kritisch sowohl für Clients als auch für Serversysteme eingestuft werden. Wir wollen nicht näher auf Sinn und vor allem Unsinn des Betriebs von Browser- und E-Mail-Software jeglicher Couleur auf Servern eingehen, sondern allen IE-Nutzern den Sammelflicken zusätzlich zu den beiden oben genannten Fixes dringend ans Herz legen, auch wenn das Paket anscheinend nicht vollständig getestet wurde: Der Frame-übergreifende Aufruf der Methode execScript funktioniert nach der Installation nicht mehr (Q316059).

Eine weitere Schwachstelle im IE, besser gesagt in dessen JScript-Implementierung, betrifft vor allem Benutzer des Instant Messengers in Verbindung mit Hotmail. Das Sicherheitsloch erlaubt es, mittels eines einfachen Skripts zum einen, alle Kontakte aus der IM-Konfiguration auszulesen und zum anderen, Nachrichten an diese Kontakte zu schicken. Für den Empfänger dieser Nachrichten scheint es, als ob der betroffene Benutzer der Absender sei. Es existiert bereits ein IM-Wurm namens JS_Menger.Gen, der für seine Verbreitung die JScript-Schwachstelle ausnutzt. Schaden richtet er dabei allerdings keinen an, sieht man von den typischen Begleitschäden eines Wurms wie zusätzlicher Netzverkehr und potenzieller Imageverlust der Betroffenen ab. Ein Patch war bis Redaktionsschluss nicht verfügbar.

Am 12. Februar veröffentlichte CERT eine Warnung gleich vor mehrfachen Sicherheitslücken in zahlreichen Implementierungen des Simple Network Management Protocols (SNMP). Wer sich allerdings die Liste der betroffenen Implementierungen durchliest, kommt nicht umhin, sich zu fragen, ob nicht SNMP selbst ein massives Sicherheitsloch ist und abgeschaltet gehört. Jene Liste umfaßt so ziemlich alles, was in der IT-Welt Rang und Namen hat und reicht von 3Com über Cisco, FreeBSD, IBM, Lotus, Lucent, Netscape, Nokia, Novell bis hin zu Redhat, Sun und Symantec. Bei soviel Prominenz kann Microsoft natürlich nicht fehlen. Die Redmonder brauchten nur fünf Stunden, um auf die CERT-Warnung mit einem Security Bulletin zu antworten, das freilich noch keinen Patch enthielt. Der folgte drei Tage später und behebt einen Buffer Overflow im SNMP-Dienst, den ein Angreifer für eine DoS-Attacke oder sogar für das Starten eigenen Codes ausnützen könnte. Bisher ist der Hotfix allerdings nur für Windows 2000 und XP erhältlich (Q314147).

Ein weiterer Buffer Overflow mit ähnlichem Gefährdungspotenzial findet sich in Microsofts Telnet-Dienst. In Redmond stuft man das Risiko als mäßig ein und hat einen Hotfix bereitgestellt (Q307298).

Windows-Domains können bekanntlich durch sogenannte Vetrauensbeziehungen miteinander verbunden werden. Grob gesprochen bedeutet das, dass Benutzer, die sich in der einen Domäne authentisiert haben, auch in der anderen Domain als authentisiert gelten. Dafür übermittelt erstere Domäne eine Liste von Security IDs (SIDs) die den Benutzer und alle eventuellen Mitgliedschaften in Sicherheitsgruppen beschreibt. Leider verwendet die vetrauende Domain diese Liste allzu sorglos: es wird nicht überprüft, ob alle SIDs wirklich aus der ursprünglichen Domain stammen, vielmehr erhält der Benutzer alle Rechte, die den fraglichen SIDs zugeordnet sind. Daraus kann man eine ziemlich schmale Sicherheitslücke konstruieren, wenn man annimmt, dass es in der ursprünglichen Domain jemanden gibt, der die SID des Administrators der Zieldomäne irgendwie in die Liste schmuggeln kann. Das Irgendwie gestaltet sich dann auch etwas schwierig, ist aber letztendlich möglich.

Der Hotfix, den Microsoft anbietet, behebt das Problem nicht direkt, sondern installiert ein Feature namens SIDfiltering. Wer SIDfiltering danach einschaltet, stellt dadurch sicher, dass sich in der fraglichen SID-Liste nur IDs aus der Ursprungsdomäne befinden; alles andere wird herausgefiltert. Leider zerstört man damit auch alle transitiven Vetrauensstellungen, die in einem Wald von Active-Directory-Domains ja unverzichtbar sind (Q289243, Q289246).

Dieser Hotfix ist übrigens im Windows Security Rollup Package enthalten, das den Großteil aller relevanten Sicherheits-Patches seit Servicepack 1 umfaßt. Wer dieses Paket installiert, darf sich weitgehend sicher fühlen, zumindest für den Moment (Q311401).

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)