DFN-CERT: Hintergrundinformationen zu den Schwachstellen in der Microsoft ATL-Bibliothek

Inhaltsverzeichnis

Dieser Artikel wurde vom DFN-CERT veröffentlicht. heise Security präsentiert ihn mit dessen freundlicher Genehmigung.

COM und ActiveX

Das Component Object Model (COM) ist eineTechnologie in Microsoft Windows, die die Kommunikation und Modularisierung von Software-Komponenten unterstützt. Das Modell ist Client/Server orientiert,wobei ein Client ein COM-Objekt initialisiert und dessen Funktionen nutzt. Als eine wichtige Eigenschaft ist das COM unabhängig von der Programmiersprache. COM-Objekte können beispielsweise in Visual Basic oder C++ implementiert werden. Für die Kommunikation werden vom COM-Objekt mehrere Interfaces bereit gestellt, die vom Client angefragt und verwendet werden können. COM-Objekte oder Server können in verschiedenen Varianten implementiert sein:

• In-Process Server: Diese Variante läuft in dem Prozessraum des Clients und ist in der Praxis als dynamische Bibliothek (DLL) realisiert. D.h. die DLL wird vom Client zur Laufzeit nachgeladen. In-Process Server sind die gebräuchlichste Variante.
• Local Server: Lokale COM-Objekte sind ausführbare Programme, die in einem separaten Prozessraum ablaufen.
• Remote Server: Das COM-Objekt kann auf einem entfernten System ausgeführt werden (Distributed Component Object Model).

Die Kommunikation zwischen Client und COM-Objekt wird durch die COM-Laufzeitumgebung realisiert. Dabei werden je nach Server-Variante unterschiedliche Mechanismen zur Interprozess-Kommunikation verwendet. Jedes COM-Objekt wird über eine eindeutige und globale ID (GUID) identifiziert, die als Class-IDentifier (CLSID) bezeichnet wird. Die Verwaltung der Objekte geschieht in der Windows Registry unter dem Zweig "HKEY_CLASSES_ROOT\CLSID", unter dem alle Objekte registriert sind.

ActiveX Controls sind eine Spezialisierung von COM-Objekten. Das heißt, alle ActiveX Controls sind erweiterte COM-Objekte. Sie werden hauptsächlich vom Internet Explorer verwendet, um zusätzliche Funktionen und Schnittstellen zum Windows Betriebssystem zur Verfügung zu stellen. Als eine weitere Eigenschaft können ActiveX Controls dynamisch durch Skript-Sprachen instanziiert und verwendet werden. Beispielsweise kann ein ActiveX Control auf eine Datenbank zugreifen und die Ergebnisse dynamisch der Webseite zur Verfügung stellen.

Sicherheitsmodelle für ActiveX Controls

ActiveX Controls laufen im Prozessraum des Internet Explorers und haben vollständigen Zugriff auf alle Windows-Resourcen mit den Rechten des Benutzers. Deshalb ist ein Sicherheitsmodell notwendig, um deren Missbrauch zu verhindern. Um die Installation von nicht-autorisierten ActiveX Controls zu verhindern, sind diese digital signiert. Dadurch kann die Installation von Controls aus nicht vertrauenswürdigen Quellen verhindert werden. Für die eigentliche Sicherheit ist der Autor des ActiveX Control verantwortlich. Dieser muss die Funktionalität so weit einschränken, dass ein Client das Control nicht für Angriffe missbrauchen kann.

In der Praxis bedeutet dies, dass alle Daten von außen entsprechend gefiltert werden müssen und nur sichere Aktionen zugelassen werden dürfen, wenn beispielsweise auf das Dateisystem oder Netzwerk zugegriffen wird. Als Sicherheitsmechanismus kann der Autor beim Erzeugen der Controls explizit angeben, ob dieses im Internet Explorer durch Script-Code instanziiert werden kann (Safe for Scripting). Weiterhin kann die Initialisierung des Objektes mit persistenten Daten erlaubt werden (Safe for Initialization). In diesem Fall kann das ActiveX Control durch Script-Code bespielsweise mit dem Inhalt einer beliebigen Datei oder Inhalten eines Webserver initialisiert werden. Beispiel ist das Microsoft Video Control (msvidvtl.dll), das kürzlich aufgrund einer kritischen Schwachstelle [10] aufgefallen ist.

Um die Verwendung eines ActiveX Controls im Internet Explorer permanent zu sperren, kann das Kill-Bit für das Control gesetzt werden. Dafür wird in dem Registry-Zweig

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InternetExplorer\
  ActiveX Compatibility\<CLSID des ActiveX-Steuerelements>

ein Schlüssel "Compatibility Flags" angelegt, der den spezifischen Wert für das Kill-Bit enthält ("0x00000400"). Dieser Vorgang wird unter [2] beschrieben.

Grundlagender Active Template Library (ATL)

Wie oben beschrieben läuft die Kommunikation zwischen Client und COM-Objekt (bzw. ActiveX Control) über Interfaces. Dabei muss jedes COM/ActiveX Objekt eine Reihe von Interfaces implementieren. Um diesen Aufwand drastisch zu reduzieren, gibt es in Microsoft Visual Studio die Active Template Library (ATL). Diese Bibliothek stellt Templates in Form von Code zur Verfügung, die die notwendigen Interfaces (z.B. IUnknown) implementieren. Wenn ein neues ActiveX Control auf der Basis der ATL implementiert werden soll, wird also ein Skelett-artiger Code für die Implementierung der Interfaces eingefügt. Dies hat allerdings zur Folge, dass Schwachstellen in der ATL sich auch auf alle Controls auswirken, die auf der Basis der ATL implementiert werden.

Da Client und COM-Objekt sich in unterschiedlichen Prozessräumen oder sogar auf unterschiedlichen Computern befinden können, wird eine Normalisierungsschicht für die Daten benötigt. Dafür werden von der ATL abstrakte Datentypen zur Verfügung gestellt. Ein Beispiel ist der Datentyp Variant.

Die Schwachstellen in der ATL-Bibliothek

In der ATL-Bibliothek wurden mindestens zwei kritische Schwachstellen [11,12] gefunden. Die erste ist bei der Analyse der Schwachstelle im Microsoft Video Control (msvidvtl.dll) in [10] aufgefallen. Dieses ActiveX Control kann innerhalb einer HTML-Seite mit einer Datei initialisiert werden, die aus dem Netzwerk geladen wird. Ist der Inhalt der Datei ungültig, wird innerhalb der Funktion ATL::CComVariant::ReadFromStream ein fehlerhafter Pointer auf einen Buffer verwendet und es kommt zu einem Buffer Overflow. Da die Schwachstelle in der Active Template Library vorhanden ist, stand fest, dass alle weiteren ActiveX Controls und Windows Komponenten potentiell betroffen sind, die die ATL in dieser Form verwenden. Die Schwachstelle ist ausführlich in [3,9] beschrieben worden.

Die zweite Schwachstelle in der ATL ist von Ryan Smith von den VeriSign iDefense Labs entdeckt worden und ist bereits veröffentlicht worden. Im Moment liegen uns außer der Vortragsankündigung [4] aber noch keine weiteren Informationen vor. Die Ausnutzung dieser Schwachstelle ermöglicht es, die Blockade von ActiveX Controls durch das Kill-Bit zu umgehen. Dadurch wäre es möglich, beliebige bereits gesperrte ActiveX Controls aufzurufen und bekannte Schwachstellen auszunutzen. Das heißt, viele eigentlich schon geschlossene Schwachstellen würden wieder ausnutzbar sein. Bislang sind nur spärliche Informationen über diese Schwachstelle vorhanden. Allerdings wird in [9] darauf hingewiesen, dass die Schwachstelle im Zusammenhang mit der Instanziierung von COM-Objekten durch ATL Property Maps steht. Die Bedingungen, unter denen ActiveX Controls verwundbar sind, werden für Entwickler in [8] beschrieben.

Gegenmaßnahmen von Microsoft

Als Gegenmaßnahme hat Microsoft Updates in den Advisories [5,6] zur Verfügung gestellt. In [5] werden Updates für Visual Studio zur Verfügung gestellt, in denen die Schwachstellen in der ATL geschlossen wurden. Dies ermöglicht den Entwicklern, Schwachstellen in den aktuell verwundbaren und zukünftigen ActiveX Controls zu schliessen. Allerdings werden dadurch nicht die Schwachstellen in den gegenwärtig installierten betroffenen ActiveX Controls geschlossen. Weiterhin ist im Moment weder die Identität noch die genaue Anzahl der betroffenen ActiveX Controls bekannt. Deshalb werden mit dem Advisory MS09-034 [6] zwei generische Mechanismen im Internet Explorer eingeführt, die in [7] beschrieben werden:

• Als erste Gegenmaßnahme wurde bei ATL-basierten Controls der Zugriff auf persistente Daten verändert. Laut [7] ist dies dadurch realisiert, indem nach bekannten, problematischen Code-Mustern gesucht wird.
• Die zweite Gegenmaßnahme ist drastischer. Dafür wurde ein neuer Feature Control Key "FEATURE_RESTRICT_OBJECT_DATA_ATTRIBUTE" eingeführt. Durch Setzen von Feature Control Keys in einer Gruppen-Policy können zentral Cluster von Windows Systemen abgesichert werden. Ist dieser Key aktiviert, werden alle Controls daran gehindert, persitente Daten bei der Initialisierung zu laden. Technisch ist das durch Sperren der Interfaces IpersistStream und IpersistStorage realisiert worden. Da diese Maßnahme zu deutlichen Einschränkungen im System führen kann, ist sie nicht per Default aktiviert.

Update vom 3.8.2009:

Inzwischen sind mit [13] weitere Informationen zu der Schwachstelle in der ATL [12] veröffentlicht worden, die die Umgehung des Kill-Bits ermöglicht. Allgemein bieten COM- oder ActiveX-Objekte Unterstützung für Persistenz. Diese kann beispielsweise dazu verwendet werden, um ein ActiveX Control mit entsprechenden Daten zu initialisieren oder den Zustand eines Objektes zu speichern. Um die Implementierung von Objekt-Persistenz zu erleichtern, existieren in der Active Template Library (ATL) mehrere Template-Klassen. Das heißt, alle COM- oder ActiveX-Objekte, die mit der ATL-Bibliothek erzeugt wurden, unterstützen per Default Persistenz. Der Fehler in [12] liegt wie bei der Schwachstelle im Microsoft Video Control [10] in der Funktion ATL::CComVariant::ReadFromStream. Diese Funktion wird je nach Objekt-Aufruf bei der Initialisierung eines ActiveX Objektes aufgerufen, um dem Objekt Daten aus dem Dateisystem oder aus dem Netzwerk zur Verfügung zu stellen. Beispielsweise wird durch den Exploit für das Microsoft Video Control über die ".data" Eigenschaft diese Funktion aufgerufen, um die Datei "logo.gif" zu lesen.

<object classid="clsid:0369B4E6-45B6-11D3-B650-00C04F79498E" data="logo.gif" /> 

Allerdings lässt sich dieser Funktion über den Mechanismus ein serialisertes Objekt übergeben (Variant-Typ VT_DISPATCH). Ist dies der Fall, wird das Objekt über die Funktion ReadFromStream initialisiert. Allerdings wird bei diesem Vorgang versäumt, das Kill-Bit des neu erzeugten Objektes zu überprüfen. Das heißt, über diesen Mechanismus lässt sich ein ActiveX Objekt aufrufen, das eigentlich durch Kill-Bit blockiert werden soll. Zwar können keine beliebigen Methoden des Objektes verwendet werden, es reicht allerdings beispielsweise für das Microsoft Video Control aus, um desses Schwachstelle trotz gesetztem Kill-Bit auszunutzen. In [13] werden weitere betroffene ActiveX Objekte genannt.

Wie bereits oben beschrieben, können die Schwachstellen in der ATL nur dadurch direkt geschlossen werden, indem alle ActiveX Controls, die mit der ATL erzeugt wurden, mit der fehlerfreien Version der ATL neu zu übersetzen. Als Sofortmaßnahme wurde ein Patch in Microsoft Systembibliotheken eingebunden, die vom Internet Explorer und den betroffenen ATL-Objekten verwendet werden. Dies ist deshalb möglich, weil die Funktion CcomVariant::ReadFromStream von diesen Bibliotheken abhängig ist. Das heißt, diese Funktion ruft Funktionen in den Bibliotheken auf, die dann beispielsweise auf das Dateisystem zuzugreifen. Nach unserem Wissen bewirkt der Patch, dass in den Systembibliotheken die Aufrufe durch die Funktion ReadFromStream abgefangen und auf die bekannten Schwachstellenmuster untersucht werden. Ist ein verwundbares Muster gefunden worden, wird das Verhalten soweit abgeändert, dass die Schwachstelle umgangen wird.

Update vom 12.8.2009

Inzwischen hat Microsoft das Advisory MS09-037 [15] herausgegeben, in dem die Schwachstellen jetzt direkt in einigen Windows Programmen geschlossen wurden (Z.B. Windows Media Player und Microsoft Outlook Express).

Weiterhin wurde eine neue Schwachstelle [16] in der ATL korrigiert. Microsoft weist in dem Advisory MS09-037 darauf hin, dass im Gegensatz zu den anderen Schwachstellen nur die eigene Version in Windows XP und Windows Server 2003 betroffen ist. Die ATL Version in Visual Studio beinhaltet diese Schwachstelle also nicht. Es sind damit nur ActiveX Controls betroffen, die auf der privaten Version der ATL basieren.

Wie bei den vorher beschriebenen Schwachstellen existiert diese aufgrund eines Fehlers beim Lesen von Datenstrukturen des Typs Variant. Diese Datenstruktur ist vom Gebrauch von Variablen in schwach typisierten Programmiersprachen wie beispielsweise Visual Basic motiviert. In der ATL wird sie von der Klasse CComVariant unterstützt.

Um eine Variant-Variable verwenden zu können, wird diese mit VariantInit initialisiert und mit VariantClear wieder frei gegeben. Der Variable kann während der Laufzeit dynamisch ein Typ zugewiesen werden. Weiterhin kann der Typ dynamisch geändert werden - beispielsweise lässt sich der String "3.14" zur Laufzeit in eine Fließkommazahl konvertieren. Als weitere wichtige Eigenschaft, können Variant-Variablen serialisiert und in dieser Form beispielsweise in einer Datei persistent gespeichert werden. Dies unterstützt die ATL, indem für jedes ActiveX Control automatisch Code eingefügt wird, der Interfaces für die Persistenz implementiert. Die serialisierten Variablen lassen sich dann mit der bekannten Funktion CcomVariant::ReadFromStream wieder einlesen. Damit schliesst sich der Kreis: wird zum Beispiel

<object classid="clsid:0369B4E6-45B6-11D3-B650-00C04F79498E" data="logo.gif" />

aufgerufen, werden stark vereinfacht die folgenden Schritte ausgeführt:

• Das ActiveX Objekt wird initialisiert. Um die Daten aus "logo.gif" dem Objekt zur Verfügung zu stellen, wird beim Objekt das Interface angefragt, um diese laden zu können. Dies resultiert in dem Interface IPersistStreamInit.
• Die Load-Methode des Interfaces IPersistStreamInit wird aufgerufen. Diese ruft später ReadFromStream auf, um die Daten zu lesen und als Variant zu deserialisieren. Dies ist der kritische Abschnitt, in dem die oben genannten Schwachstellen ausgelöst werden.

Der Grund für das Auftreten dieser Schwachstelle liegt letztendlich in der Komplexität und Mächtigkeit der Variant Datenstruktur.

Referenzen:

[1] Microsoft, Overview of the out-of-band release, http://blogs.technet.com/srd/

[2] Microsoft, So verhindern Sie die Ausführung von ActiveX-Steuerelementen in Internet Explorer: http://support.microsoft.com/kb/240797

[3] Dennis Elser und Halvar Flake, Poking around MSVIDCTL.DLL: http://addxorrol.blogspot.com/2009/07/poking-around-msvidctldll.html

[4] Microsoft, The Language of Trust: Exploiting TrustRelationships in Active Content: http://blackhat.com/html/bh-usa-09/bh-usa-09-speakers.html

[5] Microsoft, Microsoft Security Bulletin MS09-035: http://www.microsoft.com/technet/security/bulletin/ms09-035.mspx

[6] Microsoft, Microsoft Security Bulletin MS09-034: http://www.microsoft.com/technet/security/bulletin/ms09-034.mspx

[7] Microsoft, Internet Explorer Mitigations for ATLData Stream Vulnerabilities, http://blogs.technet.com/srd/archive/2009/07/28/internet-explorer-mitigations-for-atl-data-stream-vulnerabilities.aspx

[8] Microsoft, Active Template Library Security Updatefor Developers, http://msdn.microsoft.com/en-us/visualc/ee309358.aspx

[9] Microsoft, ATL, MS09-035 and the SDL, http://blogs.msdn.com/sdl/archive/2009/07/28/atl-ms09-035-and-the-sdl.aspx

[10] Microsoft, Microsoft Security Bulletin MS09-032: http://www.microsoft.com/technet/security/bulletin/ms09-032.mspx

[11] MITRE, http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0901

[12] MITRE, http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2493

[13] Mark Dowd, Ryan Smith, David Dewey, "Attacking Interoperability", http://www.hustlelabs.com/stuff/bh2009_dowd_smith_dewey.pdf

[14] DVLabs TippingPoint, "Microsoft Video ActiveXControl 0day Technical Details"; http://dvlabs.tippingpoint.com/blog/2009/07/09/microsoft-video-activex-control-0day-technical-details

[15] Microsoft, "Vulnerabilities in Microsoft ActiveTemplate Library (ATL) Could Allow Remote CodeExecution (973908)", http://www.microsoft.com/technet/security/Bulletin/MS09-037.mspx

[16] MITRE, http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2494 (ju)