Benutzer:Roeme/PaX
Beginn eines neuen Artikels. Bitte noch nichts auf die entsprechende Seite stellen.
PaX ist ein Patch für den Linux-Kernel, der "geringste Rechte"-Schutz (engl. least privilege) für Speicherseiten implementiert. Der Ansatz der geringsten Rechte erlaubt Computerprogrammen nur diejenigen Aktionen durchzuführen, die sie für einen ordentlichen, regulären Ablauf benötigen und verbietet alle darüber hinausgehende. PaX wurde 2000 das erste Mal veröffentlicht.
PaX markiert Datenbereiche des Speichers als nicht-ausführbar und Programmbereiche als nicht-beschreibbar und ordnet den Programmspeicher zufällig an. Das erste verunmöglicht direkte Code-Ausführung, während das letztere sog. return-to-libc-Angriffe (ret2libc) stark erschwert, ein Erfolg eines solchen Angriffes hängt dann vorallem vom Zufall ab; es verhindert aber nicht das Überschreiben von Variablen und Pointern. Diese Massnahmen verhindern viele Exploits wie buffer overflows.
PaX wurde durch das PaX Team geschrieben. Der Hauptautor von PaX möchte anynom bleiben.
Bedeutung
Viele, wenn nicht fast alle, Sicherheitslücken bei Computern sind auf Fehlern in Programmen zurückzuführen, die es ermöglichen, die Funktion eines Programmes zu verändern, effektiv also ein "Umschreiben" des Programmes während dessen Ausführung erlauben. So zeigen die ersten 44 Ubuntu Security Notices, dass 41% der Angriffsmöglichkeiten aus buffer overflows resultieren, 11% aus integer overflows und 16% von anderer, falscher Behandlung von nicht erwartungsgemässen Daten. Diese Typen von Programmfehlern ermöglichen es oft, Schadcode einzuschleusen und auszuführen; im Beispiel machen sie 61% aus, ohne Berücksichtigung von Überschneidungen. Die oben durchgeführte Analyse ist sehr ungenau, ein umfangreichere Untersuchung würde sicherlich andere Zahlen ergeben (sowohl höher als auch tiefer), zeigt aber grundsätzlich die Problematik auf.
Viele Würmer, Viren und Übernahmeversuche beruhen auf der Veränderung von Speicherinhalten, so dass Schadcode ausgeführt wird; oder auf Ausführung von Speicherinhalten (durch Falschadressierung) die eigentlich Daten darstellen sollen. Wenn die Ausführung solcher Anweisungen verhindert werden könnte, würde solche Schadsoftware nur noch wenig bis gar keinen Schaden anrichten können, sogar nach Installation auf dem Computer; viele könnten überhaupt nicht mehr installiert werden (z.B. der Sasser-Wurm).
PaX wurde entworfen, genaus dies für eine grosse Anzahl möglicher Angriffe zu tun, und dies auf einem sehr allgemeinen, breit anwendbaren Weg. Er verhindert die Ausführung von missbräuchlichem Code durch Kontrolle des Zugriffes auf den Speicher (lesen, schreiben, Zugriff auf Programmcode sowie Kombinationen davon) und dies, ohne die Ausführung von normalen Code zu verhindern. Mit einem kleinen Overhead reduziert PaX dadurch viele Exploits auf "Denial of Service"-Angriffe: Exploits, die dem Angreifer normalerweise root-Zugriff, Zugriff auf wichtige Daten oder anderen Schaden anzurichten erlauben würden, würden das betroffene Programm nunmehr abstürzen und das restliche System unbehelligt lassen.
Ein DoS-Angriff ist natürlich unangenehm und resultiert oft in Verlust von Zeit oder anderen Ressourcen; jedoch werden keine Daten kompromittiert oder beschädigt wenn PaX eingreift. Trotzdem kann ein DoS-Angriff in gewissen Umgebungen absolut nicht akzeptierbar sein; es gibt level-of-service-Verträge oder andere Bedingungen, die einen erfolgreichen Einbruch in ein System weniger kostenintensiv machen als die Reduktion oder Verlust der Verfügbarkeit eines Dienstes. In diesem Licht betrachtet ist der Ansatz von PaX nicht überall angemessen, in vielen Fällen jedoch ist es eine brauchbare Methode um vertrauliche Daten vor Sicherheitsbrüchen zu schützen.
Viele, aber nicht alle, Programmierfehler verursachen eine Verfälschung des Speicherinhaltes. Von den Fehlern, die dies ermöglichen und absichtlich herbeigeführt werden können, ermöglichen einige das Programm verschiedene Dinge durchführen zu lassen, für die es nicht vorgesehen wurde, wie z.B. eine privilegierte Shell zu erhalten. Der Fokus von PaX ist nicht das Finden und Korrigieren solcher Fehler, sondern das Verhindern und Isolieren der Exploits dieser Fehler. Wie im oberen Absatz angetönt, wird eine Untermenge dieser Fehler in ihrer Schwere heruntergestuft; Programme werden beendet statt ihre Dienste fehlerbehaftet weiterhin anzubieten.
PaX verhindert buffer-overflows nicht direkt; stattdessen verhindert es viele dieser und ähnlicher Programmierfehler ausgenutzt werden um unberechtigt Zugriff auf ein Computersystem zu erhalten. Andere Systeme wie "Stack-Smashing Protector" und "StackGuard" versuchen buffer-overflows direkt zu verhindern und das entsprechende Programm bei Entdeckung zu terminieren. Dieser Ansatz wird "Stack-Smashing" genannt und versucht die Angriffe abzuwehren bevor sie überhaupt durchgeführt werden können. Der allgemeinere Ansatz von PaX hingegen verhindert Schaden nachdem der Angriff beginnt. Obwohl beide Methoden die selben Ziele erreichen können, sind sie nicht völlig redundant. Dadurch wird ein Betriebssystem bei Verwendung beider Methoden prinzipiell sicherer. Es gibt bereits Linux-Distributionen, die beide Methoden benutzen.
Einschränkungen
PaX kann Fehler im Design von Programmen oder des Kernels, die einen Missbrauch der angebotenen Funktionen erlauben, nicht verhindern. Diese Fehler sind im Prinzip so auch nicht festellbar. Als Beispiel kann mag man einen Script-Interpreter betrachten, der Zugriff auf Dateien und Netzwerk erlaubt und diese Funktionen ungenügend schützt: Der Angreifer könnte auf Dateien von anderen Benutzern zugreifen, ohne dabei am Programm etwas 'verbiegen' zu müssen. PaX kann auch nicht alle "format string"-Angriffe abwehren, die beliebiges Lesen und Schreiben in Datenbereiche des Speichers durch bereits existierenden Code erlauben; der Angreifer braucht weder interne Adressen zu wissen noch fremden Code einzuschleusen um diesen Typ Angriff durchführen zu können.
Die PaX-Dokumentation beschreibt die folgenden drei Klassen von Angriffen, vor denen PaX zu schützen versucht. Sie behandelt sowohl Angriffe, die PaX abwehrt, als auch solche, die nicht abgewehrt werden. Alle setzen ein vollständiges, positions-unabhängiges Programm mit Schutz des Programmspeichers und zufälliger Anordnung des Addressbereiches voraus. Folgende Angriffe können dann blockiert werden:
- Angriffe, die fremden Code einschleusen und ausführen,
- Angriffe, die existierenden Code nicht in dem vom Programmiere vorgesehenen Ablauf ausführen (ret2libc),
- Angriffe, die existierenden Code mit falschen Daten ausführen
Da das Ziel von PaX Schaden statt Angriffe zu verhindern ist, ist es nicht möglich, alle Angriffe zu verhindern. Genau betrachtet, ist es sogar logisch unmöglich, jeden Angriff zu verhindern (Satz_von_Rice).
- Die dritte Klasse ist trotz PaX 100%-ig möglich, wenn der Angreifer keine Kenntnis von Adressen des angegriffenen Programmes benötigt.
- Die zweite und dritte Klasse sind dann zuverlässig möglich, wenn der Angreifer zwar Kenntnis von Adressen benötigt, diese aber durch Auslesen des Adressbereiches des angegriffenen Programmes erlangen kann. Dies ist möglich, wenn das Ziel einen entsprechenden Bug hat, der den Zugriff auf diese Informationen erlaubt, z.B. wenn der Angreifer Zugriff auf /proc/(pid)/maps hat.
Es existiert hierfür ein Patch, der alle Werte für Adressbereiche und Inodes in jeder Informationsquelle, die vom userland erreichbar ist, ausnullt. Dieser Patch ist zur Zeit jedoch nicht in PaX enthalten.
- Die zweite und dritte Klasse sind mit geringer Erfolgswahrscheinlichkeit möglich, wenn der Angreifer Kenntnis von Adressen benötigt, diese aber nicht erhalten kann (brute-force und raten ausgenommen). Die ASLR-Dokumentation[1] beschreibt wie man die geringe Erfolgswahrscheinlichkeit genauer messen kann.
- Die erste Klasse ist möglich, wenn der Angreifer das Programm benutzen kann, um eine Datei anzulegen, zu beschreiben und via mmap() in den Speicher einblenden kann. Dies verlangt jedoch, dass die Angriffsmethoden der zweiten Klasse möglich sind; es gelten also die selben Bedingungen wie ebenda beschrieben. Obwohl nicht Teil von PaX, wird unter anderem empfohlen, dass produktive Systeme Kontrollmechanismen einsetzen, die solche Angriffe verhindern.
Verantwortungsvolle Systemadministration ist trotz PaX immer noch notwendig. PaX verhindert oben beschriebene Angriffe, dennoch, dennoch besteht die Möglichkeit eines erfolgreichen Angriffes.
