W^X - W^X

W^X ("write xor execute", ausgesprochen W xor X ) ist eine Sicherheitsfunktion in Betriebssystemen und virtuellen Maschinen . Es ist eine Speicherschutzpolitik , wobei jede Seite in einem Prozess ‚s oder Kernel ‘ s Adressraum entweder beschreibbare oder sein kann ausführbar , aber nicht beide. Ohne einen solchen Schutz kann ein Programm CPU-Befehle (als Daten "W") in einen für Daten bestimmten Speicherbereich schreiben und dann diese Befehle ausführen (als ausführbares "X"; oder lesen-ausführen "RX"). Dies kann gefährlich sein, wenn der Schreiber des Speichers böswillig ist. W^X ist die Unix-ähnliche Terminologie für eine strikte Anwendung des allgemeinen Konzepts des ausführbaren Raumschutzes , der über den Systemaufruf gesteuert wird. mprotect

W ^ X ist relativ einfach auf Prozessoren , dass die Unterstützung feinkörnige Seite Berechtigungen, wie Sun 's SPARC und SPARC64, AMD ' s AMD64 , Hewlett-Packard 's PA-RISC , HP (ursprünglich Digital Equipment Corporation ' s) Alpha , und ARM .

W^X wurde auch auf Dateisystem-Schreib-/Ausführungsberechtigungen angewendet, um Dateischreibschwachstellen (wie im Speicher) und die Persistenz von Angreifern zu verringern. Das Erzwingen von Beschränkungen für Dateiberechtigungen kann auch Lücken in der W^X-Erzwingung schließen, die durch speicherzugeordnete Dateien verursacht werden. Das vollständige Verbot der Verwendung von beliebigem nativem Code kann auch Kernel- und CPU-Schwachstellen abschwächen, die nicht über den vorhandenen Code auf dem Computer offengelegt werden.

Kompatibilität

Einigen frühen Intel 64- Prozessoren fehlte das für W^X erforderliche NX-Bit , aber dieses tauchte in späteren Chips auf. Auf eingeschränkteren Prozessoren wie dem Intel i386 erfordert W^X die Verwendung des CS -Codesegmentlimits als " Linie im Sand ", ein Punkt im Adressraum, über dem die Ausführung nicht zulässig ist und sich Daten befinden, und unterhalb dessen es ist erlaubt und ausführbare Seiten werden platziert. Dieses Schema wurde in Exec Shield verwendet .

Linker- Änderungen sind im Allgemeinen erforderlich, um Daten vom Code zu trennen (z. B. Trampoline , die für Linker- und Bibliothekslaufzeitfunktionen benötigt werden ). Der Schalter, der das Mischen ermöglicht, wird normalerweise execstackauf Unix-ähnlichen Systemen aufgerufen

W^X kann auch ein kleines Problem für die Just-in-Time-Kompilierung darstellen , bei der ein Interpreter Maschinencode im laufenden Betrieb generiert und dann ausführt. Die einfache Lösung, die von den meisten, einschließlich Firefox , verwendet wird , besteht darin, die Seite einfach ausführbar zu machen, nachdem der Interpreter mit dem Schreiben von Maschinencode fertig ist, unter VirtualProtectWindows oder mprotectauf Unix-ähnlichen Geräten. Die andere Lösung besteht darin, denselben Speicherbereich auf zwei Seiten abzubilden, eine mit RW und die andere mit RX. Es gibt keinen einfachen Konsens darüber, welche Lösung sicherer ist: Befürworter des letzteren Ansatzes glauben, dass die Ausführung einer Seite, die jemals beschreibbar war, den Sinn von W^X verfehlt (es gibt eine SELinux- Richtlinie zur Steuerung solcher Operationen namens allow_execmod) und diese Adresse Die Randomisierung des Space-Layouts würde es sicher machen, beide Seiten in denselben Prozess einzufügen. Befürworter des erstgenannten Ansatzes sind der Meinung, dass der letztgenannte Ansatz nur dann sicher ist, wenn die beiden Seiten an zwei separate Prozesse übergeben werden und die Kommunikation zwischen Prozessen kostspieliger wäre als ein Anruf mprotect.

Geschichte

W^X wurde erstmals in OpenBSD 3.3 implementiert , das im Mai 2003 veröffentlicht wurde. Im Jahr 2004 führte Microsoft eine ähnliche Funktion namens DEP ( Data Execution Prevention ) in Windows XP ein. Ähnliche Funktionen sind für andere Betriebssysteme verfügbar, einschließlich der PaX- und Exec Shield- Patches für Linux und der NetBSD -Implementierung von PaX. In Red Hat Enterprise Linux (und automatisch CentOS ) Version 5 oder von Linux Kernel 2.6.18-8 hat SELinux die Richtlinien allow_execmem, allow_execheap, und erhalten allow_execmod, die W^X bereitstellen, wenn sie deaktiviert sind.

Obwohl W^X (oder DEP) die meiste Zeit seines Bestehens nur geschützte Userland-Programme hat, hat Microsoft es 2012 auf den Windows-Kernel auf den x86- und ARM-Architekturen erweitert. Ende 2014 und Anfang 2015 wurde W^X im OpenBSD-Kernel auf der AMD64-Architektur hinzugefügt. Anfang 2016 wurde W^X vollständig auf dem AMD64-Kernel von NetBSD und teilweise auf dem i386-Kernel implementiert.

Ab Firefox 46 im Jahr 2016 implementiert auch die virtuelle Maschine von Firefox für JavaScript die W^X-Richtlinie.

Siehe auch

Verweise

  1. ^ "Execve()-Einschränkungen für API > 28 erzwingen" .
  2. ^ "Zacks Kernel-News" .
  3. ^ "SARA eine neue gestapelte LSM" .
  4. ^ "Härten des Linux-Kernels (Serie 2.0.x)" .
  5. ^ "i386 W^X" . 17.04.2003 . Abgerufen am 19. Juni 2014 .
  6. ^ execstack(8)  -  Linux Systemadministration - Handbuch
  7. ^ a b "W^X JIT-Code in Firefox aktiviert" . Abgerufen am 29. April 2016 .
  8. ^ "Verbesserungen zur Ausnutzung der Schadensbegrenzung in Win8" .
  9. ^ "W^X-Schutz für den AMD64-Kernel" .

Externe Links