Virenschutz in Hardware? Das No Execution (NX) Feature
Nicht neu bei AMDs Opteron und Athlon 64 Prozessoren ist das nun deutlicher beworbene NX-Feature. Damit wagt sich AMD mit dem "No Execution" Feature in ein vollkommen neues Gebiet. Erstmals soll bei x86-Prozessoren eine Funktion integriert werden, die man vollmundig als Virenschutz vermarktet. Um dieses neue Element jedoch zu verstehen, muss man sich zuerst bewusst machen, wie ein Virus im allgemeinen funktioniert.
Grundsätzlich ist die Arbeitsweise immer die gleiche. Anwendungen bekommen vom Betriebssystem dynamisch einen Bereich im Arbeitsspeicher zugewiesen, in dem sie ihre temporären Daten in Puffern ablegen. Der Speicher selbst ist jedoch in drei Teile untergliedert, von denen der "oberste" Bereich als Stack die lokalen Variablen anwendungsinterner Funktionen ablegt. Zudem befinden sich dort die Adressen, über die der Zugriff auf die Daten in den beiden niedrigeren Speicherleveln möglich wird.
Abhängig von der Programmiersprache obliegt dem Programmierer die Aufgabe, mit Hilfe von bereitgestellten Funktionen den zugeteilten Bereich korrekt zu verwalten. Dazu zählt auch, dafür zu sorgen, dass die zu speichernden Daten nicht mehr Platz beanspruchen, als überhaupt für sie reserviert wurde. Sonst kann es passieren, dass sie benachbarte Speicherbereiche überschreiben. Die verbreitete Programmiersprache C, in der sowohl Windows als auch Unix und dessen Derivate entwickelt wurden, bietet zum Beispiel solche Möglichkeiten der freien Speicherverwaltung, dessen negative Auswirkungen man als BufferOverflow (Pufferüberlauf) bezeichnet.
Entwickler von Viren und Würmern machen sich diesen Fehler zu nutze, indem sie besonders viele Speichersegmente mit ihrem eigenen Programmtext überschreiben. Da das Betriebssystem bisher zwischen Daten und Programmen im Stack kein Unterschied macht und beides nebeneinander ablegt, ist es möglich, die Adressen so abzuändern, dass sie am Ende auf das fremde Programm zeigen, welches schließlich die Befehle des Virenschreibers ausführt.
Die Idee zur Lösung dieses Problems lag nun darin, den Stack einfach in einen Datenteil und einen Ausführungsteil zu untergliedern, sodass unkontrollierbare Programmausführungen im Falle von BufferOverflows vermieden werden. Da ein erheblicher Teil der Viren auf dieses Funktionsprinzip bauen, erhofft man sich auf diese Weise deutlich mehr Sicherheit für den Anwender. Neu ist die Idee allerdings nicht, da sie bei Sun seit geraumer Zeit in Solaris Betriebssystem implementiert ist. Intel und VIA haben die Umsetzung einer solchen Schutzfunktion in kommenden Prozessoren ebenfalls angekündigt. Auch für Linux existieren diverse Sicherheitsmodelle wie PAX oder SELinux, die ähnliche Ziele auf Software-Ebene verfolgen.
Es bleibt die Software in Form von Betriebssystem und Anwendung, welche dieses Feature überhaupt unterstützen muss. So gibt es unter Linux speziell angepasste Programmbibliotheken und auch mit der nächsten Windows-Generation werden die Entwickler viele Anwendungen nachträglich aktualisieren müssen, da es ansonsten zu Problemen kommen kann. Für Windows XP ist beispielsweise das bereits lange erwartete Service Pack 2 vonnöten, um NX nutzen zu können. Trotz dieser neuen Funktion darf man allerdings nicht vergessen, dass die gefürchteten BufferOverflows nur durch Fehler in der Programmierung entstehen - zum Beispiel durch mangelnde Überprüfung der Parameter. NX kann hier nur helfen, Symptome nachträglich zu mindern, die Ursache in den Programmen löst sich dadurch aber nicht.
