Skip to content

Schutzmaßnahmen in Windows 8

DEP und ASLR sind die bekanntesten Schutzmaßnahmen ("Mitigations") gegen Angriffe über Pufferüberlauf-Schwachstellen. Es gibt aber noch weitere, die im folgenden kurz vorgestellt werden. Der Schwerpunkt liegt dabei auf den Verbesserungen der Schutzmaßnahmen in Windows 8.

Mitigations in Windows 8

Auf der Black Hat USA 2012 haben Ken Johnson und Matt Miller vom Microsoft Security Engineering Center (MSEC) die "Exploit Mitigation Improvements in Windows 8" vorgestellt. Sie haben den Zweck der Mitigations sehr treffend beschrieben: "[...] increase the cost of developing reliable exploits", die Entwicklung zuverlässiger Exploits so teuer wie möglich zu machen.

Mitigations bei der Code-Erzeugung

In Windows wurde der Stackschutz durch einen Canary, der in Visual Studio durch den Schalter /GS aktiviert wird, verbessert. Es werden mehr Funktionen geschützt und unnötige Prüfungen entfernt.

Außerdem werden in Windows 8 die Grenzen von Arrays in bestimmten Szenarien geprüft, wodurch Angriffe auf verschiedene bekannte Schwachstellen verhindert werden. "Sealed" C++-Typen und -Methoden wurden optimiert und virtuelle Methoden-Aufrufe in direkte Aufrufe umgewandelt. Durch das Eliminieren indirekter Aufrufe wurde die Angriffsfläche reduziert. Und die "Virtual Table Guard" ähnelt dem Canary-Schutz für den Stack und sorgt dafür, dass das Überschreiben von vtable-Pointern erkannt wird.

Unverändert geblieben ist die Absicherung der Exception-Handler, die beim Aktivieren des Schalters /SAFESEH an einem sicheren Ort gespeichert werden. Im Fall einer Exception wird die Adresse des Exception-Handlers auf dem Stack mit der gesicherten Kopie verglichen. Stimme beide nicht überein, wird der Prozess beendet.
Ein ähnlicher Schutz lässt sich zur Laufzeit über SEHOP erreichen. Dabei wird ein symbolischer Exception-Eintrag ans Ende der Exception-Handler-Liste gesetzt. Beim Auslösen einer Exception wird die Exception-Handler-Liste durchlaufen und geprüft, ob dieser symbolische Handler erreicht werden kann. Ist das nicht der Fall, wurden die Einträge manipuliert und der Prozess beendet.

Verbesserungen der ASLR

Einige Möglichkeiten, den Schutz durch die ASLR zu unterlaufen, wurden ja bereits beschrieben. In Windows 8 wurde daher der Schutz durch die ASLR bzw. allgemein die ASLR verbessert. Da viele Exploits DLLs missbrauchen, die ASLR nicht verwenden, können in Windows 8 Prozesse auf Wunsch (in Form eines Opt-In) erzwingen, dass DLLs generell und unabhängig von deren eigenen Einstellungen an zufällige Adressen geladen werden.

Außerdem werden in Windows 8 auf Wunsch bei aktivierter ASLR alle Speicherreservierungen zufällig vergeben, so dass es keine Bereiche mit vorhersagbaren Adressen mehr gibt. Auf 64-Bit-Prozessoren wird der größere Adressraum genutzt, um eine höhere Entropie zu verwenden. Dadurch sinkt die Wahrscheinlichkeit, eine Adresse richtig zu raten, und wenn Adressen ausgespäht werden, müssen mehr als die unteren 32 Bits davon ausgespäht werden.

Und da wir gerade beim Ausspähen von Adressen sind: Das wurde erschwert, indem zum Beispiel das Ausspähen über eine beliebige Leseoperation nun weniger zuverlässig ist (es gibt keine vorhersagbaren Mappings mehr) und die oft missbrauchten Image-Pointer entfernt wurden.

Schutz des Windows-Heaps

In Windows 8 wurden einige Schutzmaßnahmen für den Heap eingeführt. Zum Beispiel arbeitet der Frontend-Allocator (LFH), der für die Reservierung von Speicherblöcken unter 16 KB zuständig ist, nun Bitmap-basiert, wodurch keine Manipulationen des LinkOffset mehr möglich sind. Der Heap-Handler kann nicht mehr freigegeben und damit auch sein Status nicht mehr korrumpiert werden. Die Commit-Routine des Heap wird mit einem globalen Schlüssel verschlüsselt, um Manipulationen des Commit-Routine-Pointers zu verhindern. Um die unerwünschte Freigabe benutzter Heap-Speicherblöcke zu verhindern, werden die Block-Header überprüft. Und bereits benutzte Blöcke können nicht mehr (neu) reserviert werden. Alle diese Schutzmaßnahmen zielen darauf ab, Angriffe auf die vom Heap verwendeten Metadaten schwieriger zu machen.

Um bestimmte Pufferüberläufe zu verhindern und/oder zu erkennen wurden die sogenannten "Guard Pages" eingeführt, die den Heap-Speicher in Blöcke aufteilen. Die Guard Pages kommen beim Reservieren großer Speicherbereiche, zwischen Heap-Segmenten und in den größtmögliche LFH-Subsegmenten zum Einsatz. Wird auf eine Guard Page zugegriffen, wird eine Exception ausgelöst.

Außerdem erfolgen die Reservierungen durch den Frontend-Allocator in zufälliger Reihenfolge, um Exploits, die auf einen ganz bestimmten Heap-Aufbau angewiesen sind, zu behindern.

Schutz des Windows-Kernels

Mit der Einführung der Sandbox in Windows 8 werden Angriffe auf den Kernel für die Cyberkriminellen interessanter, da sie darüber aus der Sandbox ausbrechen können. Um Angriffen vorzubeugen, wurde eine Reihe von Schutzmaßnahmen eingeführt oder erweitert. Zuerst einmal wurde die DEP für viele Speicherbereiche aktiviert, die unter Windows 7 noch ausführbar waren. Des weiteren wurde die Entropie, also die Zufälligkeit, der ASLR verbessert und ASLR auch für verschiedene Boot-Regionen aktiviert.

Eine neue Schutzmaßnahme ist SMEP/PXN. SMEP basiert auf Intels "OS Guard", PXN ist das ARM-Äquivalent dazu. Entsprechende Hardware vorausgesetzt, wird damit verhindert, dass der Supervisor Code aus Speicherbereichen des Benutzers ausführt, worauf die meisten aktuellen Privilegien-Eskalations-Exploits angewiesen sind. Vor allem in Verbindung mit der DEP wird die Entwicklung zuverlässiger Exploits durch SMEP/PXN erschwert.

Um die ebenfalls häufig missbrauchten Dereferenzierungen der NULL-Page zu verhindern, wird das Mappen der ersten 64K verhindert. NULL-Dereferenzierungen führen damit zu einem Denial of Service und nicht zu einer Privilegieneskalation. Außerdem wurde die Virtual DOS Machine (VDM, NTVDM) zum Ausführen von MS-DOS-Programmen per Default deaktiviert.

Für den Kernel-Pool wurden ähnliche Schutzmaßnahmen wie für den Heap ergriffen, außerdem verhindern neue Integritätsprüfungen eine Reihe bekannter Angriffe.

Des weiteren wurde das "Safe unlinking" systemweit aktiviert, die Entropie für GS und ASLR erhöht, der Object-Manager gegen Überläufe des Referenz-Zählers gehärtet und die Preisgabe von Kernel-Informationen über bestimmte Systemaufrufe abgestellt.

Sichere Default-Einstellungen

Die besten Schutzmaßnahmen sind wirkungslos, wenn sie nicht verwendet werden. Daher wurden die Default-Einstellungen weiter in Hinsicht auf die Sicherheit optimiert: Alle verfügbaren Schutzmaßnahmen werden aktiviert.

Hiermit ist das Thema "Schutz vor Angriffen über Pufferüberlauf-Schwachstellen" zumindest vorerst abgeschlossen. Das Thema der nächsten Folge steht noch nicht fest.

Carsten Eilers


Übersicht über alle Artikel zum Thema

Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 1
Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 2
Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 3
Schutzmaßnahmen: Content Security Policy gegen XSS, Teil 4
Schutzmaßnahmen: Der Pufferüberlauf im Überblick
Schutzmaßnahmen: Canary und DEP gegen Pufferüberlauf-Schwachstellen
Schutzmaßnahmen: ASLR gegen Pufferüberlauf-Schwachstellen
Schutzmaßnahmen: ASLR kann unterlaufen werden
Schutzmaßnahmen: Weitere Angriffe trotz ASLR
Schutzmaßnahmen in Windows 8

Trackbacks

Dipl.-Inform. Carsten Eilers am : Drucksache: Windows Developer 7.16 - Alles im Fluss?

Vorschau anzeigen
Im windows.developer 7.16 ist ein Artikel über Angriffe auf den Kontrollfluss von .NET-Anwendungen erschienen. Das alte Wettrennen zwischen Angreifern auf und Verteidigern von Windows-Rechnern geht in eine neue Runde: Auf der DEF CON 2