ASLR

Address Space Load Randomization

Am schlimmsten sind dabei Pufferüberläufe, die es Angreifern ermöglichen, laufende Programme wie den Internet Explorer zu infizieren, um in ein System einzudringen. Setzt sich ein Schädling im System fest, dann muss er aber die Windows-APIs nutzen, um sein Unwesen zu treiben, also etwa um Daten auszulesen oder die Systemkonfiguration zu ändern.

Hier kommt mit Address Space Load Randomization (ASLR) eine neue Kernelschutz-Funktion ins Spiel. Hintergrund: Als Einstiegspunkt dienen unter Windows die DLLs. Diese wurden in früheren Windows-Versionen immer an die gleichen Stellen im Speicher geladen.

Mit ASLR ist es für Malware unmöglich zu wissen, wo sich die APIs befinden, da System-DLLs und ausführbare Dateien jedes Mal beim Systemstart an einem anderen Ort landen. Dafür stehen dem Speicher-Manager beim Start 256 verschiedene Adressen zur Verfügung. Wenn eine bestimmte DLL geladen wird, wählt der Speicher-Manager einen zufälligen Ort aus, an dem er sie im Speicher ablegt.

Und einen weiteren Vorteil hat die Verschiebungsstrategie von ASLR: Adressbereiche werden dichter gepackt als bei früheren Windows-Versionen, sodass es mehr zusammenhängenden freien Speicherplatz gibt.

Code Integrity Check

Als Schreckgespenster moderner Art gelten Kernel-Mode-Rootkits. Mit "normaler" Security- Software kriegt man sie nur schwer in den Griff. Das Problem ist, dass sie auf der gleichen Berechtigungsstufe wie der Kernel ausgeführt werden. Diese Schädlinge kommen meist als Kernel-Mode- Treiber daher und können das Verhalten des Kerns und anderer Treiber so ändern, dass sie selbst praktisch unsichtbar sind.

Dagegen ist die Kernelmoduscodesignierung (KMCS) ein wirksames Mittel. Sie lässt nur das Laden digital signierter Gerätetreiber zu. Die meisten Treiber erhalten Signaturen über das WHQL (Windows Hardware Quality Lab), doch man kann den Code auch selbst signieren. Dazu braucht man ein gültiges Zertifikat.

Der Autor versieht den Code dann digital mit einem Hashwert (Prüfsumme), signiert den Hash mit einem privaten Schlüssel und fügt das Zertifikat und den verschlüsselten Hash in den Code ein. Beim Ladeversuch eines Treibers entschlüsselt Windows dann den im Code enthaltenen Hash mit Hilfe des Zertifikats.

Die Echtheit des Zertifikats wird auf dieselbe Weise, aber mithilfe des öffentlichen Schlüssels der Zertifizierungsstelle geprüft, der in Windows enthalten ist. Windows prüft auch, ob das zugeordnete Zertifikat mit einer der im Windows-Loader und Betriebssystemkernel eingebetteten Stammzertifizierungsstellen verkettet ist. 32-Bit-Windows Vista- Systeme prüfen die Treibersignaturen, lassen das Laden unsignierter Treiber im Gegensatz zum 64-Bit- Windows jedoch zu.

Dynamischer Kernel-Adressbereich

Auf 32-Bit-Prozessoren gibt es für Windows und die installierten Programme arge Beschränkungen des Adressbereichs. Ohne Tricks darf der Windows-Kernel selbst nicht größer als 2 GByte werden. Doch es muss auch noch Platz für Gerätetreiber, Dateisystemcache und Stack sein. Bis Windows XP hat der Speicher-Manager schon beim Start festgelegt, wie viel Platz die einzelnen Komponenten erhalten.

Das Problem dabei: Es könnte der Fall eintreten, dass ein aufgeblähter Cache an seine Grenzen stieß, während der Stack noch viel Platz übrig hatte, diesen aber nicht abgeben konnte. Bei Vista ist der Adressbereich des Kernels dynamisch und sorgt für die Zuordnung und Freigabe von Bereichen für verschiedene Zwecke, je nachdem, was die Arbeitsauslastung erfordert.

Folglich kann der virtuelle Arbeitspeicher, der verwendet wird, um ausgelagerte Puffer zu speichern, zunehmen, wenn Gerätetreiber mehr fordern, und er kann schrumpfen, wenn die Treiber ihn freigeben.