Theo De Raadt seine Pläne zur Verstärkung des W^X-Schutzmechanismus (Write XOR Execute). Der Kern des Mechanismus besteht darin, dass die Speicherseiten eines Prozesses nicht gleichzeitig zum Schreiben und Ausführen zugänglich sind. So kann der Code nur nach dem Verbot des Schreibens ausgeführt werden, während das Schreiben in die Speicherseite nur nach dem Verbot der Ausführung möglich ist. Der W^X-Mechanismus hilft, Anwendungen im Benutzerspeicher vor typischen Angriffen wie Buffer Overflows zu schützen, inklusive Stack Overflows, und ist in OpenBSD aktiv. .
Von Anfang an war klar, dass die Arbeit an W^X ein langer Weg sein würde, da eine signifikante Anzahl von Anwendungen JIT verwendet. JIT-Implementierungen können in drei Kategorien unterteilt werden:
- Die zwischen den W- und X-Zuständen wechseln, wobei sie die "Kosten" des Systemaufrufs akzeptieren. .
- Die Pseudonyme zwischen einem W- und X-Mapping desselben Speichers erstellen.
- Die „schmutzigste“ Variante — Modelle, die W|X-Speicher zulassen, das gleichzeitige Schreiben und Ausführen ermöglichen.
Derzeit gibt es deutlich weniger Programme, die die dritte Variante nutzen, und mehr, die die erste und zweite verwenden. Da jedoch Programme mit W|X JIT (insbesondere Chromium und Iridium) erforderlich waren, wurde die Option zur Einbindung des Dateisystems „wxallowed“ hinzugefügt. Diese ermöglicht es, den Speicher sowohl für die Ausführung als auch für das Schreiben zu verwenden, vorausgesetzt, die ausführbare ELF-Datei ist mit dem Marker „wxneeded“ versehen und die Anwendungen selbst werden zusätzlich durch Mechanismen geschützt. und Dies dient dazu, die Liste der verwendeten Systemaufrufe und der für die Anwendung zugänglichen Teile des Dateisystems entsprechend einzuschränken.
Zur weiteren Erschwerung der Ausnutzung von Schwachstellen in solchen Anwendungen wurde eine Ergänzung des Mechanismus vorgeschlagen. , das überprüft, ob ein Systemaufruf aus einem schreibbaren Speicherbereich erfolgt. Wenn die Seite schreibbar ist, wird der Prozess zwangsweise beendet. So kann ein Angreifer Systemaufrufe nicht ausnutzen und muss versuchen, die benötigten Gadgets in der JIT-Implementierung zu finden oder sogar die wesentlich schwierigere Arbeit der Auffindung von Stubs für Systemaufrufe direkt innerhalb der Implementierung zu leisten. .
Die Prozesse von Chrome/Iridium sind bereits recht zuverlässig durch pledge und unveil geschützt, aber das Verbot der Verwendung von Systemaufrufen wie write(2) hat offensichtliche Vorteile, da es dem Angreifer zusätzliche Schwierigkeiten bereitet. Schwierigkeiten können jedoch auch auftreten, wenn die JIT-Implementierung native Systemaufrufe aus W|X-Speicher verwendet. Es gibt jedoch Grundlagen zur Hoffnung, dass man damit nicht konfrontiert wird, da die ABI mehrfach geändert wurde, aber niemand je von Problemen berichtet hat.
Die Änderungen sind bereits in den regelmäßigen Snapshots des OpenBSD-CURRENT-Zweigs verfügbar; alle Interessierten sind eingeladen, Tests durchzuführen.
Ein gesonderter Kommentar von Theo zu den Neuigkeiten über den neuen Modus in Chrome/Iridium ist angebracht. . Aus seiner Sicht ist dies für einige Nutzungsszenarien akzeptabel, allerdings wahrscheinlich nicht für alle, da in diesem Modus die CPU-Belastung offensichtlich zunehmen wird. Derzeit funktioniert Chrome im Wesentlichen, wenn 'wxallowed' für /usr/local deaktiviert ist, obwohl Probleme mit bestimmten Erweiterungen (zum Beispiel Ghostery) auftreten können. Theo hofft dennoch, dass der JITless-Modus bald vollständig funktionsfähig sein wird.
Quelle: opennet.ru
