Zufällige Speicherzuweisung: Windows-Bug hebelt Sicherheitsmechanismus ASLR aus

Inhaltsverzeichnis

Ein seit Windows 8 bestehender Programmierfehler führt dazu, dass der Sicherheitsmechanismus Address Space Layout Randomization (ASLR) von Windows 8, 8.1 und 10 unter bestimmten Voraussetzungen nicht richtig funktioniert. Das fand Sicherheitsforscher Will Dormann vom US-amerikanischen CERT Coordination Center (CERT/CC) heraus. In einem Sicherheitshinweis fasst das CERT/CC weitere Details zusammen.

"System-wide mandatory ASLR" bewirkt statische Zuweisungen

ASLR sorgt normalerweise dafür, dass in den Speicher geladenen Prozessen Adressbereiche auf Zufallsbasis zugewiesen werden. Angriffstechniken wie etwa Buffer-Overflow-Attacken, die auf der Vorhersagbarkeit von Prozessadressen beruhen, laufen dann mit höherer Wahrscheinlichkeit ins Leere. Der Sicherheitsmechanismus ist Bestandteil des Enhanced Mitigation Experience Toolkit (EMET) und des Schutzpakets Windows Defender Exploit Guard, das seit dem Fall Creators Update fester Bestandteil von Windows 10 ist. Sowohl EMET als auch der Exploit-Schutz ermöglichen das systemweite Erzwingen von ASLR, auch "system-wide mandatory ASLR" genannt.

Eben dieser systemweite Mechanismus funktioniert jedoch nicht: Dormanns Tests ergaben, dass geladene Anwendungen nach dem Reboot und erneutem Laden wieder an derselben Speicheradresse landen – trotz aktiviertem ASLR. Dies trifft sowohl auf Win 8 und 8.1 in Kombination mit EMET als auch auf Win 10 samt Exploit-Schutz zu. Nicht von dem Fehler betroffen sind Anwendungen, deren Entwickler den Sicherheitsmechanismus mit der Linkeroption /DYNAMICBASE bewusst implementiert haben und bei denen sich das Erzwingen von ASLR somit erübrigt.

Registry-Eintrag als Workaround

Wie aus dem Sicherheitshinweis des CERT/CC hervorgeht, funktioniert "System-wide mandatory ASLR" seit Windows 8 nur noch dann ordnungsgemäß, wenn zugleich auch das Feature "system-wide bottom-up ASLR" aktiv ist. Dabei handelt es sich um eine ASLR-Variante mit verbesserter Entropie.

Um beide Funktionen zu aktivieren und damit das Problem zu lösen, empfiehlt das CERT/CC den Import (oder das Editieren) des folgenden Registry-Keys als Workaround für alle betroffenen Windows-Versionen:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel]
"MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00

Das CERT/CC weist in diesem Zusammenhang auch darauf hin, dass der über die Windows-Defender-Oberfläche erreichbare Exploit-Schutz in Windows 10 zwar ebenfalls die Option biete, Bottom-Up-ASLR systemweit zu aktivieren. Mehr noch: Das Feature sei auf der Defender-GUI sogar standardmäßig als aktiviert gekennzeichnet. Da diese Einstellung jedoch nicht mit dem systeminternen (falsch gesetzten) Registry-Wert korrespondiere, schaffe momentan nur das manuelle Editieren der Registry wirklich Abhilfe.

Microsoft bestätigt "unerwartetes" ASLR-Verhalten

Microsoft hat mittlerweile ein Statement veröffentlicht, das die Erkenntnisse des CERT/CC bestätigt. Der Hersteller bezeichnet das von Will Dormann beobachtete Verhalten allerdings nicht als Programmierfehler, sondern als "unerwartetes Verhalten" und "Konfigurationsproblem".

Neben einer tabellarischen Auflistung der möglichen ASLR-Konfigurationen nebst Resultaten umfasst das Statement auch einen zweiten Workaround für Windows 10. Demnach bewirkt die Kombination der Einstellungen "obligatorische ASLR" und "Bottom-up-ASLR" über die Windows-Defender-Oberfläche, dass das systemweite ASLR so funktioniert, wie es soll.

[Update: 13:51 - 22.11.17]: Die Meldung wurde um Informationen aus einem Microsoft-Statement ergänzt. (ovw)