Execute Disable Bit
Diese Feature ist nicht neu und sorgte schon durch den Athlon 64 unter dem Namen NX-Bit für Furore. Was sich dahinter verbirgt haben wir bisher noch nicht ausführlich geklärt, was uns dazu veranlasst das ganze nun etwas näher zu betrachten. Der Sinn des Execute Disable Bits, wie es Intel nennt, soll das Ausführen von schädlichem Code durch einen Pufferüberlauf verhindern. Schön und gut, werden sich viele sagen, was soll ich nun damit anfangen?
Um das zu klären, bedarf es zuerst etwas weiter auszuholen: Ein normaler 32 Bit PC mit x86 Architektur kann einen maximalen Adressbereich von 2^32 Byte (rund 4 GByte) adressieren. Allerdings verwendet man hierbei ein Verfahren, welches sich Paging nennt. Der Grund dafür ist einfach. Vorrangig wird es benutzt um einem Betriebssystem bzw. seinen Programmen die Möglichkeit zu bieten die vollen 4 GByte Adressraum auszunutzen, auch wenn gar nicht soviel Hauptspeicher vorhanden ist. Hierbei wird ein virtueller Adressraum gebildet der aus 2^20 (1.048.576) Pages zu je 2^12 (4 KByte) besteht. Daraus ergibt sich dann wieder die Grenze von 4 GByte. Um zu wissen wo und in welchem physikalischen Speicher sich die virtuelle Adresse befindet, wird für jede Page ein Eintrag im Page
Table gemacht. Durch die MMU (Memory Management Unit) des Prozessors und mit Hilfe der erwähnten Page Tabelle werden dann die physikalischen Adressen berechnet.
Um zu verstehen was bei einem Pufferüberlauf passiert, muss man ferner wissen, dass ein PC so etwas wie einen Stack besitzt. Ein Stack ist ein Teil im Hauptspeicher der vor allem dafür reserviert ist Rücksprungadressen von Unterprogrammen abzuspeichern. Jedes Mal wenn ein Unterprogramm aufgerufen wird, legt es seine Rücksprungadresse auf dem Stack ab und läuft das Unterprogramm ab bis es fertig ist, wonach es seine Rücksprungadresse zum Hauptprogramm wieder aus dem Stack holt. Hierbei setzt der oftmals zitierte Pufferüberlauf an. Gelingt es hier nun die Rücksprungadresse so zu verändern, dass sie nicht auf das Hauptprogramm sondern auf eine vorher eingeschleuste, als harmlos getarnte Datei (zum Beispiel ein Bild, Audio oder Videodatei) zeigt, so wird die Bitfolge in dieser Datei als Code ausgeführt. Dieser als Datei getarnte Code kann im Grunde alles beinhalten, was es dem Angreifer also ermöglicht beliebig gefährlichen Code auf dem Zielrechner auszuführen.
Das Problem besteht darin, dass bei der Paging-Methode nirgends festgehalten ist welcher Speicherteil mit Code und welcher nur mit Daten gefüllt ist. Gäbe es so eine Kennzeichnung dann wäre es auch nicht mehr möglich eine Bitfolge aus einem Bild als Code auszuführen.
Hierbei kommt das Execute Disable Bit zum Einsatz. Die Idee dahinter ist, in jeden Page Table Eintrag ein Bit zu setzen, wenn die jeweilige Page ausführbaren Code beinhaltet, oder sie eben kein Bit bekommt, falls sie nur Daten beinhaltet. Dadurch wird es unmöglich Daten die als solche vom Betriebsystem markiert worden sind als Code auszuführen. Um diese Bit in der Page Table überhaupt noch unterbringen zu können, benötigt es allerdings einiger Klimmzüge, denn eigentlich ist die Größe der Einträge begrenzt und alle vorhandenen Bits schon für diverse andere Dinge in Verwendung. Die Lösung des Problems ist eine alte Erweiterung namens PAE (Physical Adress Extension), durch die es x86 Prozessoren möglich ist mit Hilfe eines 36 Bit breiten Adressbuses und einiger Modifizierungen in der MMU, 64 GByte zu adressieren. Hierdurch wachsen auch die Einträge der Paging Table, wodurch sich Platz für das Execute Disable Bit findet. Dadurch muss allerdings PAE immer aktiviert sein, sonst kann das Feature sowohl bei AMD unter dem Namen NX-Bit, wie auch bei Intel unter dem Namen XD-Bit nicht genutzt werden. Zudem kann das XD-Bit nur genutzt werden wenn das Betriebsystems mit einer passenden Unterstützung daherkommt - bei Windows XP erst ab SP2. Nötig wird das, weil das Betriebsystem den alleinigen Zugriff auf die Page Tabelle besitzt. Jedes gestartete Programm das in den Hauptspeicher geladen wird muss also dementsprechend markiert werden. Der ausführbare Codebereiche und die zugehörigen Pages erhalten dann XD-Bit 0 (Code), während die anderen zum Programm zugehörigen Pages mit einem XD-Bit 1 (Daten) versehen werden, was der CPU ein Ausführen von Code in diesen Bereichen verweigert.
Dieser Schutz vor einem Pufferüberlauf kann allerdings niemals einen Virenscanner oder andere Sicherheitssysteme wie Firewalls ersetzen, da es vielzählige andere Atacken gibt, darunter die altbekannten Dential of Service (DoS) Angriffe oder normale Viren und Trojaner.
Autor: Pascal Heller
