Microsoft will Schutz vor Buffer Overflows verbessern
In Service Pack 1 für Vista, Service Pack 3 für Windows XP und Windows 2008 soll sich die Datenausführungsverhinderung zur Laufzeit an- und abschalten lassen. Damit sollen auch ältere, nicht DEP-kompatible Anwendungen mit DEP laufen können.
- Daniel Bachfeld
Der beste Schutz nützt nichts, wenn er deaktiviert ist. Einige Windows-Entwickler schalten in ihren Anwendungen nach Meinung von Microsoft offenbar zu oft den Schutz vor Buffer Overflows aus, damit diese fehlerfrei funktionieren. Dem wollen die Redmonder mit einer neuen API in Service Pack 1 für Vista, Service Pack 3 für Windows XP und Windows Server 2008 entgegnen, mit denen sich die Datenausführungsverhinderung zur Laufzeit an- und abschalten lässt. Der auch Data Execution Prevention (DEP) oder No Execute (NX) genannte Schutz verhindert die Folgen eines Pufferüberlaufs. Ist er aktiviert, hält Windows seine Anwendungen an, wenn im Datensegment unerlaubt manipuliert wurde. Ein Angreifer kann zwar beispielsweise mit präparierten Daten einen Stack manipulieren und eigenen Code einschleusen, ausführen kann er ihn jedoch nicht mehr.
Nach Angaben von Microsoft erzeugen aber Versionen von Visual Studio C++ vor 2005 genau solchen Code, da einige Klassen Code dynamisch generieren (Thunks). Konkret nennt Michael Howard im Microsoft-Blog ältere Active Template Librarys (ATL) als Verursacher. Da DEP in solchen Fällen anschlägt, deaktivieren Entwickler diese Funktion beim Übersetzen mittels Linker-Option für ihre Anwendung. Allerdings läuft dann die gesamte Anwendung ohne DEP und bietet möglicherweise einen Angriffspunkt.
Neue APIs sollen das Aktivieren- und Deaktivieren auch zur Laufzeit gestatten. Dies gilt allerdings nur für 32-Bit-Anwendungen, bei denen der Schutz vor Buffer Overflow über Canarys beziehungsweise Stack Cookies realisiert ist. Die API SetProcessDEPPolicy erlaubt es, Richtlinien für laufende Prozesse zu definieren. Dabei stehen verschiedene Parameter zur Wahl:
- 0x00000000: Schaltet DEP für diesen Prozess ab
- PROCESS_DEP_ENABLE (0x00000001) Schaltet DEP für diesen Prozess an
- PROCESS_DEP_ENABLE | PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION: Schaltet DEP an, verhindert aber, dass ATLs Thunks nutzen können
Die letzte Option ist nach Meinung von Microsoft die wichtigste: Damit laufen auch nicht DEP-kompatible ATL-Komponenten, obwohl für den Prozess DEP aktiviert ist. Darüber hinaus kommen die Funktionen GetSystemDEPPolicy und GetProcessDEPPolicy hinzu. Howard führt in seinem Blog ein Codeschnippsel auf, mit dem sich die neue API unter Windows nutzen lässt. Ein Manko der API erwähnt Howard jedoch ebenfalls: SetPRocessDEPPolicy liefert oft einen wenig aussagekräftigen Fehler zurück (5, Access Denied), der aber nicht zwangsläufig meine, dass der Zugriff verboten sei. Vielmehr deute er darauf hin, dass die Richtlinie nicht kompatibel mit den bisherigen Systemeinstellungen sei, etwa weil beim Linken bereits die Option /NXCOMPAT benutzt wurde oder weil Windows so eingestellt sei, dass es grundsätzlich auf DEP beharre.
Statt solche Krücken zu benutzen, steht es Entwicklern natürlich frei, Anwendungen mit Tools zu schreiben, die keine Problem mit DEP haben. Ab Visual Studio C++ 2005 soll dies der Fall sein.
Siehe dazu auch:
- New NX APIs added to Windows Vista SP1, Windows XP SP3 and Windows Server 2008, Blog von Michael Howard
(dab)
