Erweiterter Speicherschutz in IE10

IEBlog Deutsch

Blog des Internet Explorer-Entwicklerteams

Erweiterter Speicherschutz in IE10

  • Comments 2

Internet Explorer 10 verfügt über deutlich verbesserte Speicherschutzmaßnahmen, sodass Sicherheitslücken weniger einfach ausgenutzt werden können und Benutzer sicherer im Internet unterwegs sind. Diese Verbesserungen erschweren und verteuern die Entwicklung von Exploits und machen somit Angreifern das Leben schwer.

Bösartige Social Engineering-Software wurde nur deshalb zur bevorzugten Methode von Angreifern, Code auf den Computer ihrer Opfer einzuschleusen, da Browsersicherheitslücken in den letzen Jahren seltener wurden und außerdem schwieriger auszunutzen sind. Jedoch attackieren Angreifer Browser und Add-Ons wieder direkt, da IE9 und der Schutz durch dessen SmartScreen-Filter von immer mehr Benutzern verwendet wird.

Im heutigen Beitrag werde ich die Bedrohungsszenarien sowie den vorhandenen Schutz in IE9 vorstellen und erläutern, wie die neuen Speicherschutzmaßnahmen von IE10 noch mehr Sicherheit bieten.

Angriffe auf Webbrowser

Das Ziel von Angreifern bei der Ausnutzung von Speicher-Sicherheitslücken besteht darin, den Pfad für die Codeausführung des Browsers so zu verändern, dass von Angreifern eingeschleuster Code ausgeführt wird. Dazu muss ein Angriff in zwei Punkten erfolgreich sein. Der Code, den ein Angreifer ausführen möchte, muss auf dem Computer des Opfers gespeichert sein. Derartiger Code wird auf zwei Wegen eingeschleust. Ein Angreifer kann böswilligen Code durch eine Methode wie Heap Spraying im Speicher ablegen. Oder ein Angreifer verwendet eine als Return Oriented Programming bekannte Methode, um auszuführenden Code auszuwählen, der bereits im Speicher vorhanden ist.

Außerdem muss der Angreifer eine Sicherheitslücke ausnutzen können, um das Ausführen von Code grundlegend zu verändern, beispielsweise eine Pufferüberlauf-Sicherheitslücke. So kann der Codepfad zu der Adresse geändert werden, an der sich der auszuführende Code befindet.

Bei einem typischen Pufferüberlaufangriff wird ein speziell erstelltes Dataset im Threadstapel platziert, dass einen Überlauf des zugewiesenen Puffers zur Folge hat und andere Datenstrukturen überschreibt. Angreifer versuchen, Datenstrukturen (z. B. Ausnahmehandler-Datensätze oder die Rückgabeadresse einer Funktion) zu überschreiben. So können sie den Datenstrom auf einen Speicherort ihrer Wahl umleiten.

Grafische Darstellung, wie beim Schreiben einer Datenmenge in einen lokalen Puffer, die dessen Zuweisung überschreitet, wichtige Teile des Stapels überschrieben werden und einen Absturz verursachen können Durch die Übermittlung speziell erstellter Daten kann ein Angreifer die Rückgabeadresse überschreiben und die Codeausführung auf einen beliebigen Speicherort umleiten.

Andere Angreifer nutzen Use-after-free-Sicherheitslücken, bei denen einer Anwendung vorgetäuscht wird, dass diese auf ein freigegebenes Objekt zugreift, dessen Speicher für einen anderen Zweck weiterverwendet wurde.

Schützen des Browsers

Speicherschutztechnologien bilden die erste Schutzmaßnahme bei der Abwehr von Angreifern. Diese Technologien erschweren das Ausnutzen von Sicherheitslücken, senken die Erfolgsquote der Angriffe oder verhindern diese in anderen Fällen vollständig. Speicherschutzmaßnahmen zielen darauf ab, einen angegriffenen Browserprozess sicher zu beenden, bevor eine Sicherheitslücke erfolgreich ausgenutzt und Code des Angreifers ausgeführt werden kann. In vielen Fällen geben die Schutzmaßnahmen Herstellern genügend Zeit, einen Fix für eine Sicherheitslücke zu entwickeln und bereitzustellen, bevor die Sicherheitslücke ausgenutzt werden kann.

Die Speicherabwehrtechnologien von Internet Explorer wurden stets weiterentwickelt, um eine wirksame Abwehr neuer Angriffstechniken zu ermöglichen. Zahlreiche Abwehrmaßnahmen, wie die /GS-Compilerkennzeichnung, kamen bereits in früheren Versionen von Internet Explorer zum Einsatz, wurden jedoch im Lauf der Zeit aktualisiert und erweitert. Andere Abwehrmaßnahmen, wie ForceASLR (wird im Folgenden beschrieben), sind in IE10 neu hinzugekommen und erfordern neue Betriebssystemfunktionen.

Abwehrmaßnahmen während des Kompilierens

Compiler-Abwehrmaßnahmen stehen Softwareentwicklern zur Verfügung und sollten während der Entwicklung als bewährte Vorgehensweise eingesetzt werden. Das Internet Explorer-Team verwendet diese Abwehrmaßnahmen bei der Entwicklung von Internet Explorer im Rahmen unseres Security Development Lifecycle (SDL). Wir möchten Softwareentwickler ermuntern, eigene SDL-Prozesse einzuführen, die Abwehrmaßnahmen enthalten, die während der Kompilierung umgesetzt werden.

Die /GS-Kennzeichnung wurde mit Visual Studio .NET 2002 erstmals eingeführt und wird in allen unterstützten IE-Versionen verwendet. Hierbei handelt es sich um eine Compiler-Technologie, die es ermöglicht, in einem Anwendungsstapel einen Pufferüberlauf zu erkennen. Zur Laufzeit werden als „Canary“ bezeichnete Sicherheitsmaßnahmen zu den Anwendungsstapelgrenzen hinzugefügt. Beispielsweise wird bei einem Überlaufangriff gegen die Zieladresse ein Canary zwischen dem Stapelpuffer und einer Rückgabeadresse überschrieben. Dadurch kann der Prozess den Überlauf erkennen. Es wird eine Ausnahme ausgelöst, und der Prozess kann sicher beendet werden, bevor der Angreifercode ausgeführt wird.

Grafische Darstellung der Platzierung eines Canarys zwischen lokalen Variablen und der Rückgabeadresse Der Wert des Canarys wird vor der Rückgabe der Funktion mit dem ursprünglichen Wert verglichen. Wenn der Vergleich fehlschlägt, wird eine Ausnahme ausgelöst, und der Prozess kann sicher beendet werden.

Dieses Schutzprinzip wurde mit jeder neuen Version von Visual Studio weiter verbessert. Die neueste, erweiterte Version von /GS, die in Internet Explorer 9+ zum Einsatz kommt, enthält umfassend verbesserte Heuristiken zum Schutz weiterer Funktionen, darunter Nichtzeiger-Arrays und reine Datenstrukturen. Zusätzlich werden aufgrund von Optimierungen verschiedene Tests unnötig, sodass weniger Ressourcen für die Abwehrmaßnahmen erforderlich sind.

Bei der /SAFESEH-Kennzeichnung handelt es sich um eine Linker-Option, mit deren Hilfe der registrierte Ausnahmehandler einer Anwendung in einer Nachschlagetabelle an einem sicheren Speicherort gespeichert werden kann. Im Fall einer Ausnahme werden die Adressen des Ausnahmehandlers im Anwendungsstapel anhand der Nachschlagetabelle überprüft. Stimmen die Werte nicht überein, wird der Prozess beendet.

Grafische Darstellung des Vergleichs der Ausnahmeregistrierungsadressen mit den Werten in der Nachschlagetabelle Wenn die Werte nicht übereinstimmen, wird eine Ausnahme ausgelöst und der Prozess beendet.

Ein Problem der /SAFESEH-Kennzeichnung ist, dass sämtliche DLL-Module den Schutz abonnieren müssen, um den Prozess verlässlich zu schützen. Wenn ein Modul den Schutz nicht abonniert, ist dieser weniger effektiv. Während der SDL erfordert, dass sämtlicher Code von Microsoft mit SAFESEH kompiliert wird, verwenden Drittanbieter-Add-Ons diese Kennzeichnung möglicherweise nicht.

Die /DYNAMICBASE-Kennzeichnung ist eine Linker-Option, mit der eine Anwendung in die Betriebssystem-Abwehrmaßnahme Anordnung des Layouts des Adressraums (Address Space Layout Randomization, ASLR) einbezogen wird, die weiter unten in diesem Beitrag erläutert wird.

Ähnlich wie bei der /SAFESEH-Begrenzung besteht ein Problem bei der /DYNAMICBASE-Kennzeichnung darin, dass sämtliche DLL-Module diesen Schutz abonnieren müssen, damit die ASLR Exploit-Angriffe optimal abwehren kann. Jedes Modul an einem vorhersagbaren Speicherort kann Ziel eines Angreifers werden – und ein Exploit erfordert möglicherweise nur ein einziges vorhersagbares Ziel. Zahlreiche aktuelle Exploits setzen bei Browser-Add-Ons an, die den ASLR-Schutz nicht abonnieren. Beispielsweise verwendete ein Zero-Day-Exploit in Adobe Reader und Acrobat im letzten Jahr den vorhersagbaren Speicherort von Funktionen im Modul „icucnv36.dll“, dass ASLR nicht abonniert.

Abwehrmaßnahmen während der Laufzeit

Abwehrmaßnahmen, die zur Laufzeit eingesetzt werden, beziehen das Betriebssystem für den Schutz eines Prozesses mit ein.

Bei DEP/NX handelt es sich um eine betriebssystemeigene Abwehrmaßnahme, die auf grundlegenden Sicherheitsfunktionen (Datenausführungsverhinderung oder NX-Bit) moderner CPUs basiert. Diese Abwehrmaßnahme ermöglicht das Markieren von Speicherseiten als nicht ausführbare Daten. Der Prozessor verhindert das Ausführen von Code in so markieren Speicherseiten.

In der zweiten Phase eines Speicher-Exploits versucht ein Angreifer möglicherweise, eigenen Code auszuführen, der einer Datenseite im Speicher hinzugefügt wurde. Wenn die Datenseite als nicht ausführbar gekennzeichnet wurde, kann der Code des Angreifers nicht ausgeführt werden, und der Prozess wird sicher beendet.

DEP-/NX-Unterstützung wurde standardmäßig erstmals in IE8 bereitgestellt und ist auch in IE10 weiterhin vorhanden.

Bei SEHOP handelt es sich um eine Laufzeit-Abwehrmaßnahme, die einen Manipulationsschutz für Ausnahmehandler bereitstellt. Dieser ist vergleichbar mit der /SAFESEH-Compilerkennzeichnung. Diese Schutzmaßnahme fügt am Ende der Ausnahmehandlerliste des Threads einen symbolischen Ausnahmedatensatz hinzu. Im Fall einer Ausnahme wird die Ausnahmehandlerliste abgearbeitet, um sicherzustellen, dass Zugriff auf den symbolischen Datensatz besteht. Besteht kein Zugriff, zeigt dies, dass die Ausnahmehandlerkette beschädigt ist, und der Prozess wird sicher beendet. Im Gegensatz zu SafeSEH ist es bei SEHOP nicht erforderlich, dass jedes einzelne Modul diesen Schutz abonniert. Daher ist der Schutz auch dann gegeben, wenn Add-Ons nicht mit den sichersten Kennzeichnungen kompiliert wurden.

SEHOP wurde erstmalig in IE9 eingeführt und ist in IE10 weiterhin vorhanden.

ASLR wurde erstmalig unter Windows Vista eingeführt und unter Windows 8 deutlich verbessert. Wenn eine Anwendung erstmals in den Speicher geladen wird, weist ASLR dieser Anwendung eine zufällige Basisspeicheradresse zu. Zusätzlich werden auch anderen Speicherstrukturen wie Process Environment Blocks (PEB), Thread Environment Blocks (TEB), Stacks und Heaps ebenso zufällig ermittelte Speicherorte zugewiesen.

Wenn der Speicherort für Objekte und Funktionen zufällig zugewiesen wird, können Angreifer diesen nicht ermitteln. Dadurch wird Return Oriented Programming verhindert. Diese zufällige Zuordnung lässt sich am besten anhand der Metapher eines Zahlenschlosses beschreiben. Wenn ein Angreifer nicht über die richtige Kombination verfügt, hat er nur einen einzigen Versuch auf einen Glückstreffer. Rät der Angreifer falsch, schlägt der Angriff fehl, und der Prozess wird sicher beendet.

Die folgende Abbildung verdeutlicht, wie grundlegende Betriebssystemkomponenten beim Start des Systems in zufällig zugewiesene Speicheradressen geladen werden.

Grafische Darstellung der Änderung des physischen Speicherorts von verschiedenen System-DLLs zwischen dem ersten und dem zweiten Starten

ASLR wurde unter Windows 8 mehrmals verbessert. Internet Explorer 10 nutzt all diese Verbesserungen.

Sämtliche Bottom-Up- und Top-Down-Zuweisungen erfolgen mithilfe von 8-Bit-Entropie. Diese Verbesserung verringert vorhersehbare Speicherregionen, einschließlich VirtualAlloc und MapViewOfFile, deutlich.

Zufällige Anordnung des Layouts des Adressraums mit hoher Entropie (High Entropy Address Space Layout Randomization, HEASLR) erweitert den Adressraum auf 64-Bit und nutzt weitere Bits für die Entropie. Dadurch wird die Anzahl möglicher Adressen, die einem 64-Bit-Prozess zugewiesen werden können, drastisch erhöht. Alle 64-Bit-Prozesse können die vergrößerte Entropie nutzen, die von HEASLR bereitgestellt wird. Prozesse können die hohe Entropie mithilfe der neuem „Image File Execution“-Option entweder zur Linkzeit (/HIGHENTROPYVA) oder zur Ladezeit abonnieren.

Der Metro-Stil-Browser wird auf 64-Bit-Computern standardmäßig im 64-Bit-Modus ausgeführt. Dadurch werden ein wesentlich größerer Adressraum und somit ein weniger vorhersagbar angeordnetes Speicher-Layout bereitgestellt.

ForceASLR ist die womöglich wichtigste Änderung an ASLR unter Windows 8. Bei ForceASLR handelt es sich um eine neue Ladeprogrammoption, die von Internet Explorer 10 verwendet wird. Damit wird das Betriebssystem angewiesen, den Speicherort aller Module, die vom Browser geladen werden, zufällig zuzuweisen – selbst dann, wenn ein Modul nicht mit der /DYNAMICBASE-Kennzeichnung kompiliert wurde. Der ForceASLR-Schutz wurde zum Windows 8-Kernel hinzugefügt und steht jetzt auch als Update für Windows 7 bereit, das während der Installation von Internet Explorer 10 auf der Plattform installiert wird.

Um die Kompatibilität mit dieser Funktion sicherzustellen und auch ältere Internet Explorer-Versionen, die ForceASLR nicht unterstützen, durch die zufällige Speicherortzuweisung zu schützen, empfehlen wir Add-On-Entwicklern weiterhin die Verwendung der /DYNAMICBASE-Kennzeichnung.

Zusammenfassung

Ich hoffe, dass dieser kurze Überblick über die Speicherschutzfunktionen unter Windows 8 und in Internet Explorer 10 hilfreich für Sie war. Hinter den Kulissen haben wir zahlreiche weitere Verbesserungen eingeführt, um die Sicherheit zu erhöhen. Doch viele dieser Verbesserungen sind so geheim, dass wir noch nicht einmal Namen für sie haben. Es folgen weitere Beiträge zur Verbesserung der Sicherheit und der Bereitstellung einer sicheren Browser-Plattform.

– Forbes Higman, Security Program Manager, Internet Explorer