Hilfe
Neues Thema
Antworten
Am gestrigen Dienstag bestätigte der Produkt Manager der "Microsoft Security and Technology Business Unit", Mario Juarez, gegenüber einem US-Newsticker für VARs ("Value Added Reseller"), dass NGSCB ("Next-Generation Secure Computing Base", ehemals "Palladium") in seiner jetzigen Form nicht weiterentwickelt wird.
Ein Jahr, nachdem Microsoft offiziell verstärkt gegen die Sicherheitsproblematik der eigenen Produkte vorgeht, legt man in Redmond somit sehr überraschend das von Medien und Datenschutzexperten kritisierte NGSCB schlafen. Später in diesem Jahr will man einen überarbeiteten Sicherheitsplan für Longhorn, den Nachfolger von Windows XP, offenlegen.
Als Grund für die Abkehr von NGSCB nannte Juarez die Weigerung von Kunden und ISVs ("Independent Software Vendor"), ihre Software neu zu schreiben und den Code dabei an die NGSCB-API anzupassen. Die herbe Kritik in fast allen Medien wegen der offensichtlichen Verbindung zu DRM-Systemen wird ein übrigens dazugetan haben. Es war auch schwer für Microsoft, dem Endanwender klar zu machen, dass er mit Longhorn und NGSCB nicht mehr die volle Herrschaft über seinen Computer haben sollte, sondern IT-Firmen und Medien-Konzerne. Trotzdem überlegt man laut Juarez bei Microsoft, die Überreste von NGSCB noch irgendwie in Lonhorn zu integrieren.
Das Engagement legt man nun voll auf NX ("No Execute"), einem Feature des AMD64- und Intel Itanium-Prozessors, das auch noch in den Pentium 4 Einzug finden soll.
Hintergrund: NX (No Execute)
Viele Viren und Würmer nutzen Exploits nach einem einfachen System: In Datenstrukturen, insbesondere dem Stack oder dem Heap, werden durch überlange Datenpakete Überläufe (Overflows) provoziert. Anschließend wird der InstructionPointer des Prozessors manipuliert, so dass als nächstes Code aus genau dem überlangen Datenpaket ausgeführt wird. Das sind die klassischen Buffer Overflows, Integer Overflows, Heap Overflows, Format-String-Schwächen und so weiter, über die sich Würmer wie MSBlaster verbreiten. Prozessor- und Betriebssystem-Hersteller haben das schon lange als Problem erkannt, und so bieten viele Prozessoren (alle 64-Bitter) und auch Betriebssysteme wie OpenBSD 3.4 einen einfachen Schutz dagegen: Daten bleiben Daten und können überhaupt nicht ausgeführt werden.
Das Ganze nennt sich in der Unix-Welt "W^X", also "W xor X" oder "Writeable xor eXecutable". Als Daten deklarierte Speicherbereiche können nicht ausgeführt werden, Bufferoverflows und die damit verbundenen Sicherheitslücken sind so unmöglich. Nun führt auch Microsoft dasselbe mit dem SP2 für Windows XP ein: 64-Bit-Prozessoren wie Intels Itanium oder AMDs Athlon64/Opteron besitzen die für Windows notwendige Hardware-Erweiterung "NX", die Speicherbereiche als "not executable" markieren kann.
Ruft in einem solchen System eine User-Mode-Anwendung eine NX-markierte Speicherseite als Code auf, generiert der Prozessor eine Exeption (STATUS_ACCESS-VIOLATION). Das Resultat: der Prozess wird beendet. Ein Wurm wie Lovsan/MSBlaster hätte also allenfalls zum Absturz des RPC-Dienstes geführt, eine Weiterverbreitung oder Infizierung ist unmöglich. Passiert dasselbe aus irgendeinem Grund im Kernel-Mode, trapt Windows mit einem BlueScreen - und der Wurm wäre auch eliminiert. Im 32-Bit-Modus von Windows XP wird durch NX allerdings allenfalls der Stack gesichert, nur ein 64-Bit-Windows kann auch die Heaps schützen.
Intels Prescott hat, wie es aussieht, trotz IA32e keine NX-Fähigkeiten und somit einen sicherheitstechnischen Nachteil gegenüber einem AMD64-System mit einem 64bittigen Windows.
Quelle: XDial.de
Dieser Beitrag wurde von Dimension bearbeitet: 05. Mai 2004 - 23:29
Nach oben
