Ausführbarer Weltraumschutz – Wikipedia

In der Computersicherheit, Schutz des ausführbaren Speicherplatzes markiert Speicherbereiche als nicht ausführbar, sodass ein Versuch, Maschinencode in diesen Bereichen auszuführen, eine Ausnahme verursacht. Es verwendet Hardwarefunktionen wie das NX-Bit (No-Execute-Bit) oder in einigen Fällen die Softwareemulation dieser Funktionen. Technologien, die irgendwie ein NX-Bit emulieren oder bereitstellen, verursachen jedoch normalerweise einen messbaren Overhead; während die Verwendung eines von der Hardware bereitgestellten NX-Bits keinen messbaren Overhead verursacht.

Der Burroughs 5000 bot bei seiner Einführung im Jahr 1961 Hardwareunterstützung für den Schutz des ausführbaren Speicherplatzes; diese Fähigkeit blieb in seinen Nachfolgern bis mindestens 2006 erhalten. Bei seiner Implementierung der Tagged-Architektur hatte jedes Speicherwort ein zugeordnetes, verstecktes Tag-Bit, das seinen Code oder seine Daten bezeichnete. Somit können Anwenderprogramme kein Programmwort schreiben oder gar lesen und Datenworte können nicht ausgeführt werden.

Wenn ein Betriebssystem einige oder alle beschreibbaren Speicherbereiche als nicht ausführbar markieren kann, kann es möglicherweise verhindern, dass die Stapel- und Heapspeicherbereiche ausführbar sind. Dies trägt dazu bei, den Erfolg bestimmter Buffer-Overflow-Exploits zu verhindern, insbesondere solche, die Code einschleusen und ausführen, wie die Würmer Sasser und Blaster. Diese Angriffe beruhen darauf, dass ein Teil des Speichers, normalerweise der Stack, sowohl beschreibbar als auch ausführbar ist. Ist dies nicht der Fall, schlägt der Angriff fehl.

Betriebssystemimplementierungen[edit]

Viele Betriebssysteme implementieren oder verfügen über eine verfügbare Richtlinie zum Schutz des ausführbaren Speicherplatzes. Hier ist eine Liste solcher Systeme in alphabetischer Reihenfolge, jeweils mit Technologien, die von der neuesten zur ältesten geordnet sind.

Für einige Technologien gibt es eine Zusammenfassung mit den wichtigsten Funktionen, die jede Technologie unterstützt. Die Zusammenfassung ist wie folgt aufgebaut.

• Hardware-unterstützte Prozessoren: (Kommagetrennte Liste der CPU-Architekturen)
• Emulation: (Nein) oder (Architekturunabhängig) oder (Kommagetrennte Liste der CPU-Architekturen)
• Andere unterstützt: (Keine) oder (Kommagetrennte Liste der CPU-Architekturen)
• Standarddistribution: (Nein) oder (Ja) oder (Kommagetrennte Liste von Distributionen oder Versionen, die die Technologie unterstützen)
• Veröffentlichungsdatum: (Datum der ersten Veröffentlichung)

Eine Technologie, die eine architekturunabhängige Emulation bereitstellt, wird auf allen Prozessoren funktionieren, die nicht von der Hardware unterstützt werden. Die Zeile “Other Supported” ist für Prozessoren gedacht, die eine Grauzonenmethode zulassen, bei der kein explizites NX-Bit vorhanden ist, die Hardware jedoch die Emulation eines solchen auf irgendeine Weise zulässt.

Android[edit]

Ab Android 2.3 und höher verfügen Architekturen, die dies unterstützen, standardmäßig über nicht ausführbare Seiten, einschließlich nicht ausführbarem Stack und Heap.
^[1][2][3]

FreeBSD[edit]

Erste Unterstützung für das NX-Bit auf x86-64- und IA-32-Prozessoren, die es unterstützen, erschien erstmals am 8. Juni 2004 in FreeBSD -CURRENT. Es ist seit der Veröffentlichung 5.3 in FreeBSD-Releases enthalten.

Linux[edit]

Der Linux-Kernel unterstützt das NX-Bit auf x86-64- und IA-32-Prozessoren, die es unterstützen, wie beispielsweise moderne 64-Bit-Prozessoren von AMD, Intel, Transmeta und VIA. Die Unterstützung für diese Funktion im 64-Bit-Modus auf x86-64-CPUs wurde 2004 von Andi Kleen hinzugefügt, und später im selben Jahr fügte Ingo Molnar die Unterstützung für sie im 32-Bit-Modus auf 64-Bit-CPUs hinzu. Diese Funktionen sind seit der Veröffentlichung der Kernel-Version 2.6.8 im August 2004 Teil der Linux-Kernel-Mainline.^[4]

Die Verfügbarkeit des NX-Bits auf 32-Bit-x86-Kernels, die sowohl auf 32-Bit-x86-CPUs als auch auf 64-Bit-IA-32-kompatiblen CPUs laufen können, ist von Bedeutung, da ein 32-Bit-x86-Kernel normalerweise das NX-Bit nicht erwarten würde die ein AMD64 oder IA-64 liefert; Der NX-Enabler-Patch stellt sicher, dass diese Kernel versuchen, das NX-Bit zu verwenden, falls vorhanden.

Einige Desktop-Linux-Distributionen wie Fedora, Ubuntu und openSUSE aktivieren die HIGHMEM64-Option standardmäßig nicht in ihren Standard-Kernels, die erforderlich ist, um Zugriff auf das NX-Bit im 32-Bit-Modus zu erhalten, da der PAE-Modus, der erforderlich ist, um Die Verwendung des NX-Bits führt zu Boot-Fehlern auf Prozessoren vor Pentium Pro (einschließlich Pentium MMX) und Celeron M- und Pentium M-Prozessoren ohne NX-Unterstützung. Andere Prozessoren, die PAE nicht unterstützen, sind AMD K6 und früher, Transmeta Crusoe, VIA C3 und früher sowie Geode GX und LX. VMware Workstation-Versionen älter als 4.0, Parallels Workstation-Versionen älter als 4.0 und Microsoft Virtual PC und Virtual Server unterstützen PAE auf dem Gast nicht. Fedora Core 6 und Ubuntu 9.10 und höher stellen ein Kernel-PAE-Paket bereit, das PAE und NX unterstützt.

Der NX-Speicherschutz war in Ubuntu schon immer für alle Systeme verfügbar, die über die Hardware zur Unterstützung verfügten und den 64-Bit-Kernel oder den 32-Bit-Server-Kernel ausführten. Der 32-Bit-PAE-Desktop-Kernel (linux-image-generic-pae) in Ubuntu 9.10 und höher bietet auch den für Hardware mit NX-CPU-Funktion erforderlichen PAE-Modus. Für Systeme ohne NX-Hardware bieten die 32-Bit-Kernel jetzt eine Annäherung an die NX-CPU-Funktion über eine Softwareemulation, die dazu beitragen kann, viele Exploits zu blockieren, die ein Angreifer vom Stack- oder Heap-Speicher ausführen könnte.

Nicht-Ausführungsfunktionalität war auch für andere Nicht-x86-Prozessoren vorhanden, die diese Funktionalität für viele Versionen unterstützen.

Exec-Schild[edit]

Der Red Hat-Kernel-Entwickler Ingo Molnar hat einen Linux-Kernel-Patch namens Exec Shield veröffentlicht, um die NX-Funktionalität auf 32-Bit-x86-CPUs anzunähern und zu nutzen. Der Exec Shield-Patch wurde am 2. Mai 2003 in der Linux-Kernel-Mailingliste veröffentlicht, wurde jedoch für die Zusammenführung mit dem Basiskernel abgelehnt, da er einige aufdringliche Änderungen am Kerncode beinhaltete, um die komplexen Teile der Emulation zu handhaben. Die Legacy-CPU-Unterstützung von Exec Shield nähert sich der NX-Emulation an, indem die obere Codesegmentgrenze verfolgt wird. Dies erlegt nur wenige Zyklen Overhead während Kontextwechseln auf, was für alle Absichten und Zwecke unermesslich ist. Bei Legacy-CPUs ohne NX-Bit kann Exec Shield Seiten unterhalb der Codesegmentgrenze nicht schützen. ein mprotect()-Aufruf, um höheren Speicher, wie den Stack, zu markieren, markiert auch den gesamten Speicher unterhalb dieser ausführbaren Grenze. Daher schlagen die Schemata von Exec Shield in diesen Situationen fehl. Dies sind die Kosten für den geringen Overhead von Exec Shield. Exec Shield prüft auf zwei ELF-Header-Markierungen, die bestimmen, ob der Stack oder Heap ausführbar sein muss. Diese heißen PT_GNU_STACK bzw. PT_GNU_HEAP. Mit Exec Shield können diese Steuerelemente sowohl für binäre ausführbare Dateien als auch für Bibliotheken festgelegt werden. Wenn eine ausführbare Datei eine Bibliothek lädt, die eine Lockerung einer gegebenen Einschränkung erfordert, wird die ausführbare Datei diese Markierung erben und diese Einschränkung gelockert haben.

PaX[edit]

Die PaX NX-Technologie kann die NX-Funktionalität emulieren oder ein Hardware-NX-Bit verwenden. PaX funktioniert auf x86-CPUs, die nicht über das NX-Bit verfügen, wie z. B. 32-Bit-x86. Der Linux-Kernel wird immer noch nicht mit PaX ausgeliefert (Stand Mai 2007); der Patch muss manuell zusammengeführt werden.

PaX bietet zwei Methoden der NX-Bit-Emulation, genannt SEGMEXEC und PAGEEXEC. Das SEGMEXEC-Verfahren erlegt einen messbaren, aber geringen Overhead auf, typischerweise weniger als 1%, was ein konstanter Skalar ist, der aufgrund der Spiegelung des virtuellen Speichers entsteht, die für die Trennung zwischen Ausführung und Datenzugriffen verwendet wird.^[5] SEGMEXEC hat auch den Effekt, dass der virtuelle Adressraum des Tasks halbiert wird, sodass der Task auf weniger Speicher zugreifen kann, als er normalerweise könnte. Dies ist kein Problem, bis die Aufgabe Zugriff auf mehr als die Hälfte des normalen Adressraums erfordert, was selten vorkommt. SEGMEXEC bewirkt nicht, dass Programme mehr Systemspeicher (dh RAM) belegen, sondern schränkt nur den Zugriff ein. Auf 32-Bit-CPUs werden dies zu 1,5 GB statt 3 GB.

Zur Beschleunigung liefert PaX eine Methode ähnlich der Approximation von Exec Shield in der PAGEEXEC; Wenn jedoch höherer Speicher als ausführbar markiert wird, verliert diese Methode ihren Schutz. In diesen Fällen greift PaX auf die ältere Methode mit variablem Overhead zurück, die von PAGEEXEC verwendet wird, um Seiten unterhalb des CS-Limits zu schützen, was bei bestimmten Speicherzugriffsmustern zu einer ziemlich hohen Overhead-Operation werden kann. Wenn das PAGEEXEC-Verfahren auf einer CPU verwendet wird, die ein Hardware-NX-Bit liefert, wird das Hardware-NX-Bit verwendet, so dass kein signifikanter Overhead entsteht.

PaX bietet mprotect()-Einschränkungen, um zu verhindern, dass Programme Speicher auf eine Weise markieren, die für einen möglichen Exploit nützlichen Speicher erzeugt. Diese Richtlinie führt dazu, dass bestimmte Anwendungen nicht mehr funktionieren, sie kann jedoch für betroffene Programme deaktiviert werden.

PaX ermöglicht die individuelle Steuerung der folgenden Funktionen der Technologie für jede ausführbare Binärdatei:

• PAGEEXEC
• SEGMEXEC
• mprotect()-Einschränkungen
• Trampolin-Emulation
• Randomisierte ausführbare Basis
• Randomisierte mmap()-Basis

PaX ignoriert sowohl PT_GNU_STACK als auch PT_GNU_HEAP. In der Vergangenheit hatte PaX eine Konfigurationsoption, um diese Einstellungen zu berücksichtigen, aber diese Option wurde aus Sicherheitsgründen entfernt, da sie als nicht nützlich erachtet wurde. Die gleichen Ergebnisse von PT_GNU_STACK können normalerweise durch Deaktivieren der Einschränkungen von mprotect() erreicht werden, da das Programm normalerweise den Stack beim Laden mprotect() wird. Dies mag nicht immer zutreffen; In Situationen, in denen dies fehlschlägt, werden durch einfaches Deaktivieren von PAGEEXEC und SEGMEXEC alle Einschränkungen des ausführbaren Speicherplatzes effektiv aufgehoben, wodurch der Task denselben Schutz für seinen ausführbaren Speicherplatz wie ein Nicht-PaX-System erhält.

Mac OS[edit]

macOS für Intel unterstützt das NX-Bit auf allen von Apple unterstützten CPUs (ab Mac OS X 10.4.4 – der ersten Intel-Version – aufwärts). Mac OS X 10.4 unterstützte nur den NX-Stack-Schutz. In Mac OS X 10.5 haben alle ausführbaren 64-Bit-Dateien NX-Stack und -Heap; W^X-Schutz. Dazu gehören x86-64 (Core 2 oder höher) und 64-Bit-PowerPC auf den G5-Macs.

NetBSD[edit]

Ab NetBSD 2.0 und höher (9. Dezember 2004) verfügen Architekturen, die dies unterstützen, über nicht ausführbaren Stack und Heap.
^[6]

Architekturen mit Granularität pro Seite bestehen aus: alpha, amd64, hppa, i386 (mit PAE), powerpc (ibm4xx), sh5, sparc (sun4m, sun4d), sparc64.

Architekturen, die diese nur mit Region-Granularität unterstützen können, sind: i386 (ohne PAE), andere Powerpc (wie macppc).

Andere Architekturen profitieren nicht von nicht ausführbaren Stack oder Heap; NetBSD verwendet standardmäßig keine Softwareemulation, um diese Funktionen auf diesen Architekturen anzubieten.

OpenBSD[edit]

Eine Technologie im OpenBSD-Betriebssystem, bekannt als W^X, markiert beschreibbare Seiten standardmäßig als nicht ausführbar auf Prozessoren, die dies unterstützen. Auf 32-Bit-x86-Prozessoren ist das Codesegment so eingestellt, dass es nur einen Teil des Adressraums enthält, um ein gewisses Maß an Schutz für ausführbaren Speicherplatz zu bieten.

OpenBSD 3.3 wurde am 1. Mai 2003 ausgeliefert und war das erste, das W^X einschloss.

• Hardware-unterstützte Prozessoren: Alpha, AMD64, HPPA, SPARC
• Emulation: IA-32 (x86)
• Andere unterstützt: Keine
• Standardverteilung: Ja
• Erscheinungsdatum: 1. Mai 2003

Solaris[edit]

Solaris unterstützt seit Solaris 2.6 (1997) das globale Deaktivieren der Stack-Ausführung auf SPARC-Prozessoren; in Solaris 9 (2002) wurde die Unterstützung für das Deaktivieren der Stack-Ausführung pro ausführbarer Basis hinzugefügt.

Fenster[edit]

Beginnend mit Windows XP Service Pack 2 (2004) und Windows Server 2003 Service Pack 1 (2005) wurden die NX-Features erstmals auf der x86-Architektur implementiert. Der Schutz des ausführbaren Speicherplatzes unter Windows wird als “Data Execution Prevention” (DEP) bezeichnet.

Unter Windows XP oder Server 2003 wurde der NX-Schutz standardmäßig ausschließlich für kritische Windows-Dienste verwendet. Wenn der x86-Prozessor diese Funktion in der Hardware unterstützte, wurden die NX-Funktionen in Windows XP/Server 2003 standardmäßig automatisch aktiviert. Wenn die Funktion vom x86-Prozessor nicht unterstützt wurde, wurde kein Schutz gewährt.

Frühe DEP-Implementierungen boten keine Adreßraum-Layout-Randomisierung (ASLR), was potenzielle Return-to-libc-Angriffe ermöglichte, mit denen DEP während eines Angriffs hätte deaktiviert werden können.^[7] Die PaX-Dokumentation erläutert, warum ASLR notwendig ist;^[8] Es wurde ein Machbarkeitsnachweis erstellt, der eine Methode beschreibt, mit der DEP in Abwesenheit von ASLR umgangen werden könnte.^[9] Ein erfolgreicher Angriff kann möglich sein, wenn dem Angreifer die Adresse von aufbereiteten Daten wie beschädigten Bildern oder MP3-Dateien bekannt ist.

Microsoft hat die ASLR-Funktionalität in Windows Vista und Windows Server 2008 hinzugefügt. Auf dieser Plattform wird DEP durch die automatische Verwendung des PAE-Kernels in 32-Bit-Windows und die native Unterstützung für 64-Bit-Kernel implementiert. Windows Vista DEP funktioniert, indem bestimmte Teile des Speichers so markiert werden, dass sie nur Daten enthalten sollen, die der NX- oder XD-Bit-fähige Prozessor dann als nicht ausführbar versteht.^[10] Unter Windows ab Version Vista kann auf der Seite angezeigt werden, ob DEP für einen bestimmten Prozess aktiviert oder deaktiviert ist Prozesse/Details Registerkarte im Windows Task-Manager.

Windows implementiert Software-DEP (ohne die Verwendung des NX-Bits) durch Microsofts “Safe Structured Exception Handling” (SafeSEH). Bei ordnungsgemäß kompilierten Anwendungen überprüft SafeSEH, ob der Ausnahmehandler beim Auslösen einer Ausnahme während der Programmausführung von der Anwendung so definiert ist, wie sie ursprünglich kompiliert wurde. Dieser Schutz bewirkt, dass ein Angreifer nicht in der Lage ist, seinen eigenen Ausnahmehandler, den er in einer Datenseite gespeichert hat, durch ungeprüfte Programmeingaben hinzuzufügen.^[10][11]

Wenn NX unterstützt wird, ist es standardmäßig aktiviert. Windows ermöglicht es Programmen zu steuern, welche Seiten die Ausführung über seine API sowie über die Abschnittsüberschriften in einer PE-Datei nicht zulassen. In der API wird der Laufzeitzugriff auf das NX-Bit über die Win32-API-Aufrufe bereitgestellt VirtualAlloc[Ex] und VirtualProtect[Ex]. Jede Seite kann einzeln als ausführbar oder nicht ausführbar gekennzeichnet werden. Trotz fehlender früherer x86-Hardwareunterstützung wurden von Anfang an sowohl ausführbare als auch nicht ausführbare Seiteneinstellungen bereitgestellt. Auf CPUs vor NX hat das Vorhandensein des Attributs ‘executable’ keine Auswirkung. Es wurde dokumentiert, als ob es funktionierte, und daher verwendeten die meisten Programmierer es richtig. Im PE-Dateiformat kann jeder Abschnitt seine Ausführbarkeit angeben. Das Ausführungsflag existiert seit Beginn des Formats und Standard-Linker haben dieses Flag immer korrekt verwendet, sogar lange vor dem NX-Bit. Aus diesem Grund ist Windows in der Lage, das NX-Bit in alten Programmen zu erzwingen. Angenommen, der Programmierer hat sich an die “Best Practices” gehalten, sollten Anwendungen jetzt korrekt funktionieren, da NX tatsächlich erzwungen wird. Nur in wenigen Fällen gab es Probleme; Microsofts eigene .NET Runtime hatte Probleme mit dem NX-Bit und wurde aktualisiert.

Xbox[edit]

Obwohl die CPU in Microsofts Xbox nicht über das NX-Bit verfügt, setzen neuere Versionen des XDK das Codesegmentlimit auf den Anfang des Kernels .Daten (unter normalen Umständen sollte kein Code nach diesem Punkt stehen). Ab Version 51xx wurde diese Änderung auch in den Kernel neuer Xboxes implementiert. Dies brach die Techniken, die alte Exploits verwendeten, um ein TSR zu werden. Es wurden jedoch schnell neue Versionen veröffentlicht, die diese neue Version unterstützen, da der grundlegende Exploit nicht betroffen war.

Einschränkungen[edit]

Wenn Code zur Laufzeit geschrieben und ausgeführt wird – ein JIT-Compiler ist ein prominentes Beispiel –, kann der Compiler potenziell verwendet werden, um Exploit-Code zu erzeugen (z. B. mit JIT Spray), der zur Ausführung markiert wurde und daher nicht gefangen würde.^[12][13]

Return-orientierte Programmierung kann es einem Angreifer ermöglichen, beliebigen Code auszuführen, selbst wenn der Schutz des ausführbaren Speicherplatzes erzwungen wird.

Siehe auch[edit]

Verweise[edit]