Dipl.-Inform. Carsten Eilers

Sucht man in der Exploit-DB nach DEP oder ASLR, findet man inzwischen etliche Exploits, die diese Schutzfunktionen umgehen. Peter Van Eeckhoutte beschäftigt sich in seinem Exploit Writing Tutorials in mehreren Folgen mit dem Umgehen von DEP und ASLR, im Pwn2Own-Wettbewerb auf der CanSecWest mussten DEP und ASLR umgangen werden (was auch gelang), und Dino Dai Zovi hat die Grenzen der Schutzfunktionen in einem Vortrag auf der RSA-Konferenz aufgezeigt.
Es sieht so aus, als seien DEP und ASLR weitgehend wirkungslos, oder?

Microsoft: Schutzmaßnahmen umgehen ist keine Schwachstelle

Bereits mehrmals hat Microsoft Fehler, die das Umgehen der Schutzmaßnahmen wie DEP und ASLR erlauben, nicht als Schwachstelle eingestuft. Z.B. ist laut Microsoft eine Schwachstelle in Virtual PC, die in virtuellen Umgebungen das Umgehen von Schutzfunktionen wie DEP, SafeSEH und ASLR erlaubt, gar keine Schwachstelle. Und das, obwohl auch der XP-Modus von Windows 7 betroffen ist, so dass z.B. eine unter Windows XP nicht ausnutzbare Schwachstelle im XP-Modus von Windows 7 ausgenutzt werden könnte. Und auch eine Schwachstelle im Microsoft HTML Viewer, die sich ausnutzen lässt, um die Address Space Layout Randomization (ASLR) zu umgehen, wird als "technique for bypassing ASLR" und nicht als ausnutzbare Schwachstelle eingestuft.
Wenn das keine Schwachstellen sind, können DEP und ASLR wohl nicht sehr wichtig sein, oder?

Kaum jemand nutzt DEP und ASLR

Secunia hat berichtet, dass viele nicht von Microsoft stammende Programme, namentlich z.B. Java, QuickTime Player, VLC Media Player, OpenOffice.org, Google Picasa, Foxit Reader, Winamp und der RealPlayer, auf den Einsatz der Schutzfunktionen DEP (Data Execution Prevention) und ASLR (Address Space Layout Randomization) verzichten bzw. sie falsch einsetzen (Studie als PDF). Im Fall von Browser-Plugins ist die Nutzung der Schutzfunktionen meist davon abhängig, ob der verwendete Webbrowser sie nutzt, und oft werden die Besonderheiten, die zur Nutzung von DEP unter Windows XP notwendig sind, nicht berücksichtigt, so dass der Schutz erst ab Windows 7 wirksam ist. Brian Krebs hat ergänzend festgestellt, das auch viele Antiviren-Produkte auf den Einsatz der Schutzfunktionen verzichten. Wenn die Entwickler bekannter und weit verbreiteter Anwendungen und sogar die von Schutzprogrammen auf DEP und ASLR verzichten, muss deren Nutzung wohl schwierig oder unnötig sein und man sollte besser generell auf sie verzichten, oder?

3x "oder?" als Frage - 3x "Nein!" als Antwort

DEP und ASLR sind weitgehend wirkungslos?
Nein! Das sind sie nicht, auch wenn es so scheinen mag. Beide Funktionen sollen die Ausnutzung von Pufferüberlauf-Schwachstellen erschweren, nicht verhindern. Und das tun sie recht gut, auch wenn es immer wieder Möglichkeiten gibt, sie zu umgehen. Es gibt sehr viel mehr Exploits, die an DEP und/oder ASLR scheitern also solche, die trotz der Schutzfunktionen funktionieren. Also erfüllen sie ihren Zweck, und das augenscheinlich recht gut, denn sonst müsste es ja mehr Exploits geben, die trotz ihrer Nutzung funktionieren.

DEP und ASLR sind unwichtige Schutzmaßnahmen?
Nein! Unwichtig ist Microsofts Meinung dazu, ob Fehler, die ihr Umgehen erlauben, Schwachstellen sind oder nicht. Natürlich sind es Schwachstellen, aber wenn Microsoft der Meinung ist, dass es keine sind, dann sollen sie halt bei dieser Einschätzung bleiben. Dass darunter die Kunden leiden, die dadurch auf einen Patch für diese Nicht-Schwachstellen länger warten müssen und inzwischen vielleicht Opfer einer Ausnutzung dieser Nicht-Schwachstellen werden, ist bedauerlich. Aber in Windows und den Microsoft-Programmen gibt genug schwerwiegendere Schwachstellen, so dass es auf ein paar relativ harmlose mehr oder weniger auch nicht ankommt. Und wenn es irgendwann mal einen spektakulären Angriff auf ein DEP- und ASLR-geschütztes System gibt, bei dem so eine Schwachstelle ausgenutzt wurde, wird die folgende schlechte Presse Microsoft vielleicht zum Umdenken bewegen.

DEP und ASLR sind schwierig zu nutzen?
Nein! Man muss sich allerdings schon ein paar Gedanken darüber machen, wenn man ein altes Programm anpassen will, dass dadurch nicht mehr mögliche Aktionen verwendet. Code auf den Stack (oder in andere Datenbereiche) schreiben und ausführen oder Code durch direktes Anspringen der entsprechenden Speicherstelle ausführen geht damit natürlich nicht mehr. Das erste scheitert daran, dass der Code auf dem Stack nicht mehr ausführbar ist, das zweite daran, dass der Code nicht mehr immer an der gleichen Stelle im Speicher steht. Wenn davon ausgiebig Gebrauch gemacht wurde, lässt sich DEP und ASLR natürlich nicht mit einem Mausklick einschalten. OK, das Einschalten ginge schon, nur würde das Programm dann nicht mehr laufen. Aber sollten moderne Programme wirklich noch solche, inzwischen ja doch eher in Verruf geratene Techniken einsetzen? Und was für Leichen haben solche Programme wohl noch im Keller? Da wäre ja wohl sowieso mal eine gründliche Renovierung fällig, und danach klappts auch mit DEP und ASLR.

Bei neu entwickelten Programmen ist das alles kein Problem, da kann man ja von Anfang an drauf achten, keine Tricks zu nutzen, die heutzutage nur noch Cyberkriminelle verwenden. Seien wir doch mal ehrlich: Code auf den Stack schreiben und ausführen oder Code durch das Anspringen fester Adressen aufzurufen, sind doch wirklich nicht mehr "State of the Art" (um den Satz "Stand der Technik" zu vermeiden, der so unangenehm an Patente erinnert).

Hilfe zur Selbsthilfe

Microsoft hat im Oktober 2009 mit dem Enhanced Mitigation Evaluation Toolkit (EMET) ein Werkzeug zur Verfügung gestellt, mit dem sich verschiedene Schutzfunktionen nachträglich auch für fertig übersetzte Programme aktivieren lassen, ohne dass sie neu kompiliert werden müssen, auch der Quelltext muss nicht vorliegen. Inzwischen wurde eine die verbesserte Version 2 des nun lang "Enhanced Mitigation Experience Toolkit" genannten Tools angekündigt. Ein Video beschreibt die neue Version genauer.

Mehrere Artikel in Microsofts Security Research & Defense Blog beschreiben die Wirkungsweise verschiedener Schutzfunktionen. So geht es in "Understanding DEP as a mitigation technology" Teil 1 und Teil 2 allgemein um die Funktion von DEP, der tatsächliche Nutzen der Schutzfunktion lässt sich gut an der im Rahmen der "Operation Aurora" ausgenutzten 0-Day-Schwachstelle im Internet Explorer verfolgen. In weiteren Artikeln geht es z.B. um "Preventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOP", um "SEHOP per-process opt-in support in Windows 7" und um "Preventing the exploitation of user mode heap corruption vulnerabilities". Ein zweiteiliger Artikel beschreibt die Wirkung des GS-Schalters im Microsoft C/C++ Compiler, der die Erkennung von Pufferüberläufen durch den Einsatz eines GS-Cookies aktiviert: "GS cookie protection – effectiveness and limitations" und "Enhanced GS in Visual Studio 2010". Das ist nur eine Auswahl an Informationsquellen, die Dokumentation Ihrer Entwicklungsumgebung enthält sicher auch Hinweise über den Einsatz der Schutzfunktionen. Es gibt also keinen Grund, auf ihren Einsatz zu verzichten. Trauen Sie sich ruhig, die Schutzfunktionen beißen nicht. Es wäre doch Schade, wenn gerade Ihr Programm zum Einfallstor wird, nur weil Sie ein paar Compileroptionen nicht genutzt haben, oder?

Carsten Eilers