Tipps gegen Sicherheitslücken in ActiveX-Controls von Microsoft [Update]
Russische Webseiten versuchen, die ungepatchte Lücke im WMI-Control auszunutzen. Beim XML-Control bleibt unklar, wer genau betroffen ist. Abhilfe schafft das Setzen der Kill-Bits.
- Daniel Bachfeld
Die bislang ungepatchte Lücke im WMIObjectBroker-ActiveX-Control wird nach Berichten von Microsoft und des Internet Storm Center bereits vermehrt ausgenutzt. Laut Hinweisen von TippingPoint an das ISC soll es bereits eine große Zahl von Angriffen aus Russland geben, die versuchen, Besucher mit dem Trojaner Galopoper.A zu infizieren. Wie erfolgreich sie dabei sind, ist unklar, denn das verwundbare Control ist eine Komponente (WmiScriptUtils.dll) von Visual Studio 2005 – normale Heimanwender sind also von dem Problem nicht betroffen. Zudem ist das Control standardmäßig nicht aktiviert, sodass auch Entwickler nicht unbedingt Gefahr laufen, beim Besuch präparierter Seiten infiziert zu werden.
Ähnlich verhält es sich auch mit dem am vergangenen Wochenende gemeldeten Fehler im XML-Core-Services-ActiveX-Control. Dort ist nur das mit Version 4.0 mitgelieferte Control verwundbar, was aber auf Standard-Windows-Rechnern nicht zu finden sein sollte. Üblicherweise benutzt der Internet Explorer 6 die XML-Core-Services (MSXML) in Version 3.0, wie sie auf normalen XP-Installationen zu finden sind. Leider gibt auch Microsoft nicht genau an, in welchen Produkten MSXML 4.0 enthalten ist. Selbst aus Microsofts Übersicht der Versionen ist nicht zu erkennen, wo MSXML 4.0 zum Einsatz kommt. Wahrscheinlich wird es mit dem .NET Framework 2.0 mit installiert. Auch in der Works Suite 2005 Standard Edition, Visual FoxPro 8.0 sowie der Windows Small Business Server 2003 Premium Edition ist es enthalten. Zudem kann es in Anwendungen enthalten sein, die mit Visual Basic 6.0 oder Visual C++ 6.0 erstellt wurden.
Aktuell ist bereits MSXML 6.0. Zudem sind mehrere parallele Installationen verschiedender Versionen der XML-Core-Services erlaubt. Wer sichergehen will, sucht auf dem PC nach Dateien, die im Namen "msxml" enthalten und schaut sich die Versionsnummer an. Alternativ kann man auch die Registry danach durchsuchen, ob das Control registriert ist:
reg query "HKEY_CLASSES_ROOT\CLSID" /s | findstr 88D969C5-F192-11D4-A65F-0040963251E5
Im Zweifel hilft es, bis zum Erscheinen von Sicherheitsupdates, ActiveX komplett zu deaktivieren oder die genannten Controls über das Setzen ihrer Kill-Bits abzuschalten. Folgender Codeschnipsel erledigt dies laut Microsoft für das WMI-Control (als wmi.reg speichern und ausführen):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{7F5B7F63-F06F-4331-8A26-339E03C0AE3D}] "Compatibility Flags"=dword:00000400
Beim XML-Control macht es dieser Registry-Patch (als xml.reg speichern und ausführen):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{88d969c5-f192-11d4-a65f-0040963251e5}] "Compatibility Flags"=dword:00000400
Siehe dazu auch: (dab)
- Vulnerability in Visual Studio 2005 Could Allow Remote Code Execution, Warnung von Microsoft
- Vulnerability in Microsoft XML Core Services Could Allow Remote Code Execution, Warnung von Microsoft
