Skip to main content


EMET - Enhanced Mitigation Experience Toolkit

Das Enhanced Mitigation Experience Toolkit (EMET) erlaubt es, eine Reihe von Maßnahmen zum Erschweren von Angriffen über Buffer Overflow-Schwachstellen in fertigen Binaries zu aktivieren. Dazu muss weder der Sourcecode vorliegen noch das Programm mit entsprechenden Compiler-Flags neu kompiliert werden.

Realisiert wird dieser nachträgliche Schutz über die Microsoft Windows Application Compatibility Infrastructure: Eine Shim-DLL mit Namen emet.dll wird mit der zu schützenden Anwendung geladen und stellt die konfigurierten Schutzmaßnahmen zur Verfügung.

Die Schutzmaßnahmen

Außer den bereits beschriebenen Maßnahmen DEP und ASLR unterstützt das EMET ein Reihe weiterer Schutzmaßnahmen:

Die Structured Exception Handler Overwrite Protection  (SEHOP) verhindert, dass ein vom Angreifer nach einem Buffer Overflow auf dem Stack oder im Datensegment überschriebener Exception Handler (SEH) verwendet wird. Bevor das System einen Exception Handler verwendet, wird die Korrektheit der Exception Record Chain geprüft und bei einem Fehler das Programm beendet. SEHOP wurde mit Windows Vista SP1 eingeführt und ist ab Windows 7 bereits auf Per Process Opt-in-Basis verfügbar. Mit dem EMET kann SEHOP für alle Systeme ab Windows XP auf Anwendungsebene aktiviert werden.

Die Heapspray Allocation soll das mehrfache Verteilen von Schadcode im Speicher erschweren. Beim sog. Heap Spraying wird der Schadcode an so vielen Stellen im Speicher wie möglich gespeichert, um die Wahrscheinlichkeit, ihn erfolgreich anzuspringen, zu erhöhen. EMET reserviert einen Teil der dafür üblicherweise verwendeten Speicherbereiche, sodass diese vom Angreifer nicht mehr genutzt werden können und der Angriff fehl schlägt.

Das EMET reserviert die erste Seite im Speicherbereich der Anwendungen, die sog. Null Page. Das verhindert die evtuelle mögliche Ausnutzung von Schwachstellen im Zusammenhang mit versehentlichen Zugriffen auf Null-Pointer. Bisher sind keine derartigen Angriffe bekannt, es handelt sich um eine reine "Defense in Depth"-Maßnahme gegen mögliche zukünftige Angriffstechniken.

Das Export Address Table Access Filtering (EAF) verhindert Zugriffe von eingeschleustem Schadcode auf bestimmte APIs. Bevor eingeschleuster Schadcode auf APIs zugreifen kann, muss er deren Adressen ermitteln. Dazu wird meist der Export Address Table (EAT) aller geladenen Module nach für den Angriff brauchbaren APIs durchsucht. Der Filter des EMET erlaubt bzw. verbietet Lese- und Schreibzugriffe auf den EAT auf Grundlage des durchführenden Codes und verhindert dadurch für den größten Teil des zur Zeit üblichen Schadcodes das Lesen des EAT. Diese Schutzfunktion verhindert nur aktuelle Angriffe, für zukünftige neue Angriffstechniken muss sie wahrscheinlich angepasst werden.

Ein weiterer Vorteil des EMET: Auch wenn eine Anwendung ASLR nutzt, werden manche DLLs an vorhersagbare Adressen geladen. Dieses aus Sicherheitssicht äußerst ungünstige Verhalten tritt immer dann auf, wenn eine Bibliothek nicht mit der Option /DYNAMICBASE kompiliert wurde und ist formal korrekt. Das EMET erzwingt bei aktivierter Option Mandatory ASLR auch für diese DLLs eine zufällige Anordnung im Speicher.

Die zusätzlichen Schutzmaßnahmen dienen zum größten Teil dazu, Angriffe abzuwehren, bei denen DEP und ASLR bereits ausgehebelt wurden. In der Praxis konnten damit z.B. unter Windows XP Exploits für Schwachstellen im Adobe Reader unbrauchbar gemacht werden (wobei dabei ASLR nicht umgangen werden musste, da diese Maßnahme erst mit Windows Vista eingeführt wurde).

Anwendungsfälle

Als Entwickler werden Sie jetzt vermutlich abwinken: "Danke, kein Bedarf, ich kompiliere meine Programme sofort mit aktivierten Schutzmaßnahmen". Und damit haben Sie sogar Recht – zumindest zum Teil. Denn was ist mit Programmen von Dritten, deren Quelltexte sie nicht haben, die sie aber mit Ihrem Programm zusammen verwenden und ausliefern? Für die konnten Sie die Schutzmaßnahmen bisher nicht aktivieren, selbst wenn der verwendete Code ihren Einsatz eigentlich erlauben würde. Mit EMET können Sie die Schutzmaßnahmen für diese nur als Binaries vorliegenden Programme problemlos aktivieren. Gegebenfalls können Sie damit auch recht zügig die Kombination von Schutzmaßnahmen ermitteln, mit denen das Programm und die verwendeten Bibliotheken fehlerfrei arbeiten.

Leider können Sie die mit EMET geschützten Programme dann nicht mit diesem Schutz ausliefern. Aber Sie können auf die betreffenden Entwickler einwirken, damit diese den Schutz aktivieren. Und außerdem können Sie in Ihrer Anleitung beschreiben, wie die Benutzer diesen Schutz selbst realisieren können. Das mag merkwürdig anmuten, zeigt aber, dass Sie die Sicherheit Ihrer Benutzer nicht leichtfertig aufs Spiel setzen. Und wäre es nicht ziemlich peinlich, wenn Ihr Programm zwar sicher ist, die Rechner seiner Benutzer dann aber über eine von Ihnen mitgelieferte Dritthersteller-Komponente mit Schadsoftware infiziert werden?

Auch wenn Sie die Quelltexte für ein Programm haben ist es im Zweifelsfall meist einfacher, die Schutzmaßnahmen mit EMET zu aktivieren und zu testen, ob sie genutzt werden können oder Fehler verursachen und welche Kombination fehlerfrei arbeitet. Sie sparen sich damit die sonst für die Tests notwendigen Konfigurationsänderungen und Compiler-Läufe. Erst zum Schluss wird das Programm dann mit den passenden Einstellungen neu kompiliert.

EMET ist primär gar nicht für Entwickler vorgesehen – stattdessen soll es Administratoren und Benutzern eine Möglichkeit geben, auf bekannte Exploits, d.h. Code zum Ausnutzen von Schwachstellen, zu reagieren. Die Schutzmaßnahmen sind leider viel zu oft nicht aktiviert, obwohl das betreffende Programm auch mit ihnen problemlos funktioniert. Taucht nun ein sog. 0-Day-Exploit auf, d.h. ein Angriff auf eine bisher ungepatchte Schwachstelle, kann die Aktivierung der Schutzmaßnahmen diesen Angriff oft verhindern. Im Idealfall gibt es dann einen Patch, bevor die Cyberkriminellen Schadcode entwickelt haben, der die Schutzfunktionen umgeht (sofern ihnen das überhaupt gelingt).

Ein praktisches Beispiel

Ein Beispiel für so einen Einsatz liefert der Security Research & Defense Blog: Im September 2010 machte ein Exploit für eine 0-Day-Schwachstelle im Adobe Reader im Internet die Runde, der die Data Execution Prevention (DEP) durch sog. Return Oriented Programming (ROP) umging. Eigentlich hätte das durch die ASLR verhindert werden sollen. Aber der Adobe Reader verwendete eine Bibliothek (icucnv36.dll), für die ASLR nicht eingeschaltet war. Dadurch wurde die Bibliothek immer an die gleiche Speicheradresse geladen und der Schadcode konnte sie anspringen.

Wurden mit EMET für die Programmdatei AcroRd32.exe die Schutzmaßnahmen aktiviert, funktioniert der Exploit nicht mehr: Unter Windows Vista und dessen Nachfolgern wird dann für alle geladenen Bibliotheken ASLR erzwungen, sodass sie an zufällige Adressen geladen und vom Schadcode nicht mehr gefunden werden. Unter Windows XP und Windows Server 2003, in denen es noch kein ASLR gibt, sorgt das Export Address Table Access Filtering (EAF) dafür, dass der Zugriff des eingeschleusten Schadcodes auf einige APIs zu einer STATUS_STACK_BUFFER_OVERRUN-Exeception und damit der Beendigung des Programms führt.

EMET in Aktion

Ab Windows 7 werden prinzipiell alle Maßnahmen unterstützt – eine Abweichung gibt es lediglich auf 64-Bit-Systemen: Während für 32-Bit-Prozesse alle Schutzmaßnahmen zur Verfügung stehen, müssen 64-Bit-Prozesse auf das Export Address Table Access Filtering verzichten. SEHOP ist für 64-Bit-Prozesse nicht nötig und DEP wird auch ohne EMET generell erzwungen. Über EMET einstellbar sind die Heapspray Allocation, die Reservierung der Null-Page sowie die Mandatory ASLR.

Die EMET-GUI ist eigentlich selbsterklärend. Das Installationsprogramm installiert aber auch eine ausführliche Anleitung, die auch unter dieser Ankündigung im Security Research & Defense verlinkt ist.

Das EMET-Startfenster

Im oberen Teil des Startfensters sehen Sie die systemweiten Einstellungen für DEP, SEHOP und ASLR, die hier auch geändert werden können. Sie haben dabei die Wahl zwischen den Maximum Security Settings (DEP immer ein, SEHOP Opt-out auf Anwendungsebene und ASLR Opt-in auf Anwendungsebene), Recommended Security Settings (für alle Opt-in auf Anwendungsebene) und selbstgewählte Einstellungen. Einige Einstellungsänderungen erfordern einen Neustart, um wirksam zu werden – EMET weist ggf. darauf hin.

EMET Maximum Security Settings

EMET Recommended Security Settings

Im unteren Teil des Startfensters sehen Sie die Liste laufender Prozesse mit der Information, ob DEP und EMET für den betreffenden Prozess aktiviert sind oder nicht. Ganz unten finden Sie den Button, mit dem sie zu den Einstellungen für einzelne Programme kommen.

EMET Einstellungen für einzelne Programme

Programme können über die Buttons Add und Remove zur Liste hinzugefügt oder daraus entfernt werden. Beim Hinzufügen erscheint der normale Dateiauswahl-Dialog, mit dem dann die zu schützende Datei ausgewählt wird. Danach können über die Checkboxen die einzelnen Schutzmaßnahmen ein- oder ausgeschaltet werden. Änderungen an der Liste oder einzelnen Einstellungen müssen mit dem OK-Button übernommen werden. Damit sie wirksam werden, muss das neu hinzugefügte Programm (bzw. das Programm, dessen Einstellungen geändert wurden) ggf. beendet und neu gestartet werden. Danach sind die Schutzmaßnahmen aktiv und ein möglicher Angreifer hat es zumindest deutliche schwerer als vorher.

Schlussbemerkungen

Prinzipiell ist Sicherheit etwas, mit dem man nicht leichtfertig spielt. In diesem Fall spricht aber nichts dagegen, in einer ruhigen Minute auszuprobieren, für welche bisher ungeschützten Programme Sie EMET einsetzen können. Programme, die sie jetzt schützen, können später nicht einer 0-Day-Schwachstelle zum Opfer fallen. Und es ist allemal besser, jetzt in Ruhe zu testen, ob die Schutzmaßnahmen aktiviert werden können oder nicht, als später während laufender Angriffe die Maßnahmen auf die Schnelle zu aktivieren und zu hoffen, dass das Programm schon damit laufen wird.

Wenn Sie als Entwickler nur als Binary vorliegende, bisher ungeschützte Programme von Dritten mit Ihren Programmen ausliefern, erweitern Sie ihre Anleitung um Anweisungen, wie man diese Programme ggf. mit EMET schützen kann. Leider gibt es keine Möglichkeit, sie mit aktiviertem EMET-Schutz auszuliefern. Die Benutzer müssen EMET dann ggf. installieren und die Programme damit selbst schützen.


 

Autor des Artikels

Dipl.-Inform. Carsten Eilers ( www.ceilers-it.de) ist als freier Berater und Coach für IT-Sicherheit und technischen Datenschutz tätig und als Autor verschiedener Artikel und des Buches "Ajax Security" bekannt.  Seinen Blog finden Sie hier.

 



These postings are provided "AS IS" with no warranties, and confers no rights. Use of included code samples are subject to the terms specified at Microsoft - Information on Terms of Use. The content of these security articles are the own personal opinions from Carsten Eilers.

Microsoft führt eine Onlineumfrage durch, um Ihre Meinung zur -Website zu erfahren. Wenn Sie sich zur Teilnahme entscheiden, wird Ihnen die Onlineumfrage angezeigt, sobald Sie die -Website verlassen.

Möchten Sie teilnehmen?