Sind Schutzfunktionen wie DEP und ASLR überflüssig?
In der Exploit-DB tauchen immer mehr Exploits auf, die das Umgehen der Schutzfunktionen DEP (Data Execution Prevention) und ASLR (Address Space Layout Randomization) erlauben, wichtige Anwendungen einschließlich Virenscannern nutzen sie gar nicht, und Microsoft hält Fehler, die ihr Umgehen erleichtern, nicht für Schwachstellen - sind DEP und ASLR also überflüssig?
DEP und ASLR umgehen
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?
Trackbacks
Dipl.-Inform. Carsten Eilers am : Pwn2Own 2011 - Schlechtere Regeln, Googles Chrome erneut ungetestet
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues zur Sicherheit von Clients, nicht nur im Web
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Adobe: Lieber Exploits verteuern statt Schwachstellen beheben
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Kommentare zu Webcam-Spannern, EMET 4.0 und einer neuen 0-Day-Schwachstelle
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Schutzmaßnahmen: Weitere Angriffe trotz ASLR
Vorschau anzeigen