Von Detlef Jantz,
tecChannel,de
Fortsetzung von ComputerPartner-Ausgabe 07/05, Seite 35.
Kernfrage NX - Funktionsprinzip
Ein Erfolg der x86-Architektur liegt in der ständig gewahrten Abwärtskompatibilität neuer Modelle trotz der Einführung immer neuer Features. Mit fortschreitendem Alter einer Prozessorfamilie steigt deren virtueller Wert, da immer mehr Software dafür erhältlich ist. x86-PCs werden nicht so sehr wegen ihres Hardware-Designs gekauft, sondern weil dafür ein riesiges Software-Angebot vorhanden ist.
Aus dieser Notwendigkeit der zwingenden Kompatibilität zum Vorgänger lassen sich eine ganze Reihe Erweiterungen zum 386 finden, die Intel und AMD im Laufe der letzten 20 Jahre angestückelt haben.
Das Bild und die zugehörige Tabelle sind nicht als vollständige Aufzählung aller Erweiterungen zu sehen. Sie sollen vielmehr die verschiedenen Richtungen der x86-Erweiterungen aufzeigen und die Einordnung zusammengehöriger Begriffe ermöglichen.
Auch andere Prozessorhersteller wie NexGen, IDT Centaur, Cyrix, VIA C3 und Transmeta mussten sich der strengen Abwärtskompatibilität beugen. Selbst geringe Abweichungen führten immer wieder zu Rückschlägen im Markt, an denen etliche der aufgeführten Hersteller letztendlich gescheitert sind.
Schreibschutz im Page-Deskriptor
Erste Speicherschutzerweiterungen hat Intel bereits beim 80386 eingeführt. Dafür wurde ein Bit in den Page-Deskriptoren spendiert, mit denen sich eine Page zumindest schreibschützen ließ (R/W-Bit). Der damit erreichbare Effekt ist jedoch gering, da zum Beispiel der Stack-Bereich beschreibbar sein muss. Zum damaligen Zeitpunkt war aber die Problematik von sich im Daten- beziehungsweise Stack-Bereich einnistenden Virenprogrammen nicht absehbar.
Ein weiteres S/U (Supervisor/ User)-Bit im Page-Deskriptor regelt den Zugriff nur für das Betriebssystem oder auch für Anwenderprogramme. Da jedoch auch Anwenderprogramme, die bei Windows zudem oft im Kontext des Administrators laufen, sehr viel Freiheit genießen, stellt dies keinen wirklichen Schutz gegen Angriffe dar.
Über die Segmentdeskriptoren ließe sich die Sicherheit erhöhen, da der Protected Mode vier Benutzerrechtsstufen (CPL 0..3, Current Privilege Level) unterscheiden kann. Windows und Linux nutzen davon jedoch nur zwei Stufen, CPL 0 für das System und CPL 3 für User. Die Segmentverwaltung ist zudem kompliziert und alle damit verbundenen Aktionen sind sehr zeitaufwendig. Die Umgehung der Segmentverwaltung galt daher bislang als erstrebenswertes Ziel für Programmierer.
Mit den vorhandenen Möglichkeiten können der i80386 und die meisten seiner Nachfahren nicht zwischen den Speicherzugriffen Codewörter lesen (CR) und Datenwörter lesen (DR) unterscheiden. Ein Schutz vor einer Codeeinschleusung auf den Stack war daher bislang nicht möglich.
Mit dem Pentium brachte Intel eine Verbesserung des Speicherschutzes in Form des WP (Write Protect)-Bits. Es kann das Verhalten beim Paging umschalten, so dass das R/W-Bit auch im Supervisor-Mode einen Schreibzugriff verhindert. Erst dies erlaubt einen Schreibschutz von Supervisor-Seiten gegenüber dem System selbst. Dies war der erste Patch zu einem systematisch korrekteren Verhalten, der mit dem NX-Bit aktuell weiter ausgebaut wird.
Mit dem NX-Bit beim Athlon 64 erhält die Paging-Einheit eine weitere Verbesserung des Speicherschutzes, die eine genauere Unterscheidung der Speicherzugriffe erlaubt. NX ist als ein neues Bit an der obersten Stelle 63 des erweiterten Page-Deskriptors neu definiert und wird mit einer 1 aktiviert. Die Speicherseite eines solchermaßen aktivierten Page-Deskriptors darf keine Maschinencode-Leseoperationen (CR) mehr liefern. Legt ein Angreifer Code auf dem so geschützten Stack oder Datenbereich ab und versucht dann, diesen auszuführen, löst der Prozessor eine Exception aus.
Dieses NX-Bit steht allerdings nur im erweiterten Adressierungsmodus PAE zur Verfügung, der mit seinen längeren Page-Deskriptoren als inkompatible Änderung gegenüber dem 386 nicht unproblematisch ist.
Für die Schutzbits NX und WP gibt es Flags in den Kontrollregistern des Prozessors, die deren Zusatzfunktion überhaupt erst freischalten. Dort lässt sich auch das Paging mit größeren Seiten im PSE- und PAE-Modus aktivieren.
Microsoft hat zur Verbesserung der Manipulationssicherheit in Windows XP mit dem Service Pack 2 und in Windows 2003 mit dem Service Pack 1 einige Verbesserungen eingeführt. Diese betitelt der Software-Konzern mit Data Execution Prevention (DEP), zu Deutsch "Datenausführungsverhinderung" recht treffend: DEP soll das Ausführen von Code aus Datenbereichen heraus verhindern. Zum Einsatz kommen dabei mehrere Verfahren, die je nach Schutzmaßnahme unter Hardware-DEP und Software-DEP zusammengefasst sind.
Für das Hardware-DEP steht an erster Stelle das bereits beschriebene NX-Bit beim Paging-Schutz des Prozessors. Beim Hardware-DEP schützt ein 32-Bit-Windows per default nur den Stack. Das 64-Bit-Windows geht einen Schritt weiter und sichert auch die dynamischen Speicherpools. Damit ist aber immer noch keine vollständige Abdeckung aller Daten erreicht. Versucht ein Programm, Code aus einem geschützten Datenbereich auszuführen, erzeugt die Hardware-DEP die Systemfehlermeldung "STATUS_ACCESS_ VIOLATION (0xc0000005)".
Unter Software-DEP hat Microsoft mehrere Adresskontrollen an den Schnittstellen zum Betriebssystem zusammengefasst. Betrachtet man die Adresslage verschiedener Speicherbereiche eines Programms, ergibt sich folgende Reihenfolge der Blöcke: Code - Daten - Dynamische Puffer - Heap - Stack. Übergibt ein Programm bei einem Systemaufruf eine Adresse als Parameter, kann das Betriebssystem prüfen, auf welchen der Blöcke die Adresse verweist. Stellt Windows eine Inkonsistenz fest, bricht es das Programm ab.
Als wichtigstes Beispiel sei hier der Fall genannt, dass ein Programm einen Betriebssystemaufruf zur Anmeldung eines Interrupt-Vektors oder einer Callback-Routine macht. Software-DEP überprüft dabei, in welchem Block die anzumeldende Funktion abgelegt ist und akzeptiert keine Adressen aus Datenbereichen. Das Ausführen von Programmroutinen und demzufolge die Akzeptanz von Codevektoren wird somit ausdrücklich auf die Bereiche beschränkt, die der Compiler bei der Erstellung des Programms dafür angelegt hat.
Tritt der Sonderfall auf, dass ein Programm Code zur Laufzeit dynamisch erzeugt und diesen aufführen will, muss es dafür einen speziellen Speicherbereich anfordern. Dieser erhält bereits bei der Allocation eine extra Ausführungsberechtigung, sodass die Software-DEP bei einem Codesprung in diesen "Datenbereich" keinen Alarm schlägt.
Microsoft zählt die AMD64-Familie mit Opteron und Athlon 64 und den Intel Xeon mit EM64T als geeignete Prozessoren für Hardware-DEP auf. Bei allen anderen Prozessoren ist zumindest die Software-DEP einsetzbar, da sie keinerlei besondere Hardware voraussetzt. Beim Software-DEP sind in Zukunft weitere Verbesserungen zu erwarten, da das Windows-Programmiererteam die Bereichskontrollen an sehr vielen Stellen einsetzen kann. Letztlich muss der Hersteller die gesamte System-Software auf diese Möglichkeit hin durchforsten und umschreiben.
In Windows XP mit SP2 schützt Microsoft nur einen Teil der Betriebssystemroutinen und den Stack durch DEP. Das größte Problem bereitet dabei die bestehende und alte Software, die von diesen schon länger proklamierten und jetzt aktiv kontrollierten Regeln nichts wissen will. Dies gilt vor allem für Treiberprogramme, die zur Laufzeit spezielle Code-Patches und adaptierte Routinen erzeugen.
Mit dem Anspruch, unsaubere Programme trotz der Kontrollkollision mit DEP noch ausführen zu können, sind Kompromisse nötig. Diese unterlaufen und entwerten das DEP, sind aber nötig, um die Kompatibilität von Betriebssystem und Anwendungsprogrammen zu erhalten.
Wenn ein Programm sich nicht an die Regeln zur Allocation von Speicher mit Ausführungsberechtigung hält und zudem eine eigene Codeladeroutine nutzt, muss das Betriebssystem zunächst von einer Virusaktivität ausgehen. Microsoft bietet aber verschiedene Optionen an, DEP abzuschwächen, um derartige Programme dennoch laufen lassen zu können.
Zum einen kann der User über die Systemeigenschaften im Unterpunkt "Erweitert / Systemleis- tung / Datenausführungsverhinderung" bei aktiviertem DEP einzelne Programme von der Prüfung ausschließen. Zum anderen kann man dort auch das globale Verhalten von DEP einstellen. Hier stehen allerdings nur zwei der vier Optionen offen.
Eine bessere Kontrolle erlaubt der manuelle Eintrag direkt in die boot.ini. Der Schalter
/noexecute=policy_level
steuert das Verhalten.
Erstaunlich ist, dass die Default-Konfiguration DEP nicht generell aktiviert ist. Für ein sicheres System sollte man auf jeden Fall "AlwaysOn" verwenden.
Fazit
Das NX-Bit der kommenden Prozessorgeneration steht nur im erweiterten Adressierungsmodus PAE zur Verfügung. Dieser Speicheradressierungsmodus schließt bei etlichen Betriebssystemen eine Nutzung generell aus. Davon betroffen sind zum Beispiel Windows Me und Windows 98. Da der neue Hardware-Schutz aber mit Windows XP, Windows Server 2003 und aktuellen Linux-Distributionen problemlos zusammenarbeitet, profitieren ein großer Teil der installierten Basis und alle PC-Neugeräte davon.
Die Notwendigkeit, die Prozessorarchitektur des x86 umzugestalten, bleibt jedoch weiterhin bestehen. Für einen präzise einsetzbaren Speicherblockschutz bräuchte eine MMU ein umfassendes und an allen Stellen einheitliches Schutzbitangebot. Bei vier Privilegienebenen und drei Speicherzugriffswegen würden dafür fünf Bit in jedem Deskriptor genügen.
Immerhin stehen den Betriebssystementwicklern mit dem WP-Bit und aktuell dem NX-Bit etliche Möglichkeiten zur Verbesserung der Sicherheit offen. Das derzeitige Einfallstor für viele Viren, die per Buffer Overflow Code in den Stack einschmuggeln, kann NX durchaus schließen. Bedingung dafür ist die korrekte Implementierung des PAE-Modus auf allen Systemebenen, insbesondere durch Updates aller systemnahen Software, Treiber und Utilities. Solange es aus Kompatibilitätsgründen eine Option gibt, DEP zur Laufzeit zu deaktivieren, bleibt der Schutz jedoch löchrig.
Aber auch ohne neue Hardware bieten Windows XP und das SP2 eine erweiterte Schutzfunktion. Die Plausibilitätskontrolle von Callback-Adressen via Software-DEP ist sicherlich ein nützliches Feature. Doch hilft sie wenig, wenn der User sie nicht explizit einschaltet. Andere potenzielle Einfallsbereiche sind in Windows und Linux noch nicht abgesichert. Hier gilt es, die Betriebssysteme weiter nachzubessern. Insofern sind NX und das SP2 der Anfang einer strikten Entwicklung zu mehr Sicherheitsfunktionen und nicht deren Ende.
Dieser Artikel stammt von tecChan nel.de, dem Webzine für technikorientierte Computer- und Kommunikationsprofis. Unter www.tec Channel.de finden Sie weitere Beiträge zu diesem Thema.