Microsoft EMET 2.0: So soll Windows sicherer werden

Äußerst effektiv ist Heap Spray. Es funktioniert ähnlich wie ASLR und wählt zufällige Adressen, wenn der Entwickler Speicherplatz auf dem Heap anfordert. Dazu muss man wissen, dass es grundsätzlich nicht einfach ist, einen Pufferüberlauf "produktiv" auszunutzen. Mit den meisten entdeckten Pufferüberläufen kann man "nur" einen Absturz des Programms hervorrufen beziehungsweise einen Bluescreen bei Kernel-Lücken.

Ein Angreifer kann zwar in der Regel die Rücksprungadresse mit einem beliebigen Wert überschreiben, jedoch weiß er nicht, bei welcher Adresse sich sein über eine Datenstruktur eingeschmuggelter Code befindet. Er nutzt in der Regel die Tatsache aus, dass sich Computer deterministisch verhalten. Wenn bestimmte identische Bedingungen erfüllt sind, etwa exakt dieselbe Version des verwundbaren Programms, eine identische Windows-Version und so weiter, wird eine Datenstruktur immer an derselben Adresse geladen.

Bereits Kleinigkeiten verhindern die Ausnutzung eines Pufferlaufs. Wenn dieser etwa über das Laden eines Dokuments erreicht wird, funktioniert ein Exploit schon nicht mehr, wenn vor dem Schadcode-Dokument ein anderes Dokument geladen wurde.

Heap Spray verwendet absichtlich eine zufällige Adressvergabe, so dass die Adressen von Datenstrukturen nicht mehr vorhergesagt werden kann. Der Angreifer kann seinen Code daher nicht zur Ausführung bringen.

Eigentlich sollte es keine Anwendung geben, die mit aktiviertem Heap Spray nicht richtig funktioniert. Allerdings gibt es einige Programme die darauf vertrauen, dass zwei Objekte, für die unmittelbar nacheinander Speicher auf dem Heap reserviert wird, sich an bestimmten Adressen befinden. Das zeugt zwar von extrem schlechten Programmiertechniken, kommt in der Praxis aber durchaus vor.

Structured Exception Handler Overwrite Protection (SEHOP)

Die Structured Exception Handler Overwrite Protection (SEHOP) sorgt dafür, dass bei einer C++-Exception die gesamte Exception Record Chain validiert wird. Werden Modifizierungen entdeckt, beendet das Betriebssystem den Prozess sofort. Eine solche Validierung ist bereits ab Windows Vista SP1 implementiert. Sie wurde in Windows 7 noch einmal verbessert.

EMET erlaubt, die verbesserte Windows-7-SEHOP für jeden Prozess bereits ab Windows XP zu nutzen. Da es nur für 32-Prozesse Exploits gibt, die die Exception Handler überschreiben, ist dieser Schutz für 64-Bit-Prozesse nicht erforderlich.

Null-Pointer-Derefenzierung in erster Linie ein Linux-Problem

Null-Pointer-Dereferenzierungsexploits sind für Windows nicht bekannt. Betroffen sind bisher nur Linux-Systeme. Sie sind allesamt nicht durch nachlässiges Programmieren entstanden, sondern durch Überoptimierung in gcc4. Obwohl die Entwickler den Fall NULL für einen Pointer behandelt hatten, hielt der Compiler das für überflüssig und optimierte den sicherheitsrelevanten Code einfach wieder heraus. Der Bug ist inzwischen beseitigt.

Obwohl für Windows keine Exploits bekannt sind, heißt das nicht, dass es keine gibt. Das Problem hängt nicht vom Betriebssystem ab, sondern davon, welcher Compiler verwendet wird. Da es gcc4 auch für Windows gibt, können damit kompilierte Programme durchaus Schaden anrichten.

EAF bietet kaum echten Schutz

Eher nur geringen Schutz bietet Export Address Table Access Filtering (EAF). Einige Exploits durchsuchen die Export-Adress-Tabellen von DLLs wie kernel32.dll und ntdll.dll auf eine bestimmte Art und Weise. Dagegen bietet EAF Schutz. Microsoft erläutert selbst, dass dieser Schutz leicht umgangen werden könne. Er diene vor allem dazu, bereits bekannte Exploits unschädlich zu machen.

Bildergalerie

So funktioniert Microsofts Sicherheitstool EMET

zur Bildergalerie