Theo De Raadt plant, den Speicherschutzmechanismus W^X (Write XOR Execute) zu stärken. Der Kern des Mechanismus besteht darin, dass auf Prozessspeicherseiten nicht gleichzeitig zum Schreiben und Ausführen zugegriffen werden kann. Daher kann Code nur ausgeführt werden, nachdem das Schreiben deaktiviert wurde, und das Schreiben auf eine Speicherseite ist nur möglich, nachdem die Ausführung deaktiviert wurde. Der W^X-Mechanismus trägt zum Schutz von User-Space-Anwendungen vor häufigen Pufferüberlaufangriffen, einschließlich Stapelüberläufen, bei und ist in OpenBSD aktiv .
Schon zu Beginn der Arbeit an W^X war klar, dass dies ein langer Weg war, da es eine beträchtliche Anzahl von Anwendungen gab, die JIT nutzten. JIT-Implementierungen können in drei Kategorien unterteilt werden:
- Umschalten des Speichers zwischen W- und X-Zuständen unter Übernahme der „Kosten“ des Systemaufrufs .
- Erstellen von Aliasen zwischen einem Paar W- und X-Zuordnungen desselben Speichers.
- Die „schmutzigste“ Option erfordert ein W|X-Speichermodell, das gleichzeitiges Aufzeichnen und Ausführen ermöglicht.
Derzeit nutzen deutlich weniger Programme die dritte Option und mehr die erste und zweite. Da es jedoch notwendig war, Programme mit W|X JIT auszuführen (hauptsächlich Chromium und Iridum), wurde eine Dateisystem-Mount-Option „wxallowed“ hinzugefügt, die es ermöglichte, Speicher gleichzeitig zum Schreiben und Ausführen zu verwenden, falls die ausführbare ELF-Datei vorhanden war Die Datei ist mit der Markierung „wxneeded“ gekennzeichnet und die Anwendungen selbst wurden zusätzlich durch Mechanismen geschützt и um die Liste der verwendeten Systemaufrufe bzw. Teile des Dateisystems, die der Anwendung zur Verfügung stehen, einzuschränken.
Um die Ausnutzung von Schwachstellen in solchen Anwendungen noch weiter zu erschweren, wird eine Ergänzung des Mechanismus vorgeschlagen , das prüft, ob der Systemaufruf von einer beschreibbaren Speicherseite aus ausgeführt wird. Wenn die Seite beschreibbar ist, wird der Prozess zwangsweise beendet. Auf diese Weise kann ein Angreifer keine Systemaufrufe ausnutzen und muss versuchen, die erforderlichen Gadgets in der JIT-Implementierung zu finden oder sogar die schwierigere Aufgabe zu übernehmen, Systemaufruf-Stubs direkt darin zu erkennen .
Chrome/Iridium-Prozesse werden mit Pledge und Reveal bereits recht zuverlässig geschützt, aber das Entfernen der Möglichkeit, beispielsweise den Systemaufruf write(2) zu verwenden, hat offensichtlich einige Vorteile, da es dem Angreifer zusätzliche Schwierigkeiten bereitet. Allerdings kann es auch zu Schwierigkeiten kommen, wenn die JIT-Implementierung native Systemaufrufe aus dem W|X-Speicher nutzt. Es besteht jedoch Grund zur Hoffnung, dass dies nicht der Fall sein wird, da der ABI zwar mehrfach geändert wurde, aber noch nie jemand von Problemen berichtet hat.
Die Änderungen sind bereits in regulären Snapshots des OpenBSD-Current-Zweigs verfügbar, alle Interessierten sind zum Testen eingeladen.
Verwandte Neuigkeiten zum Erscheinen des Modus in Chrome/Iridium verdienen einen separaten Kommentar von Theo . Aus seiner Sicht ist dies für einige Nutzungsmodelle akzeptabel, aber wahrscheinlich nicht für alle, da dieser Modus offensichtlich die Belastung des Prozessors erhöht. Derzeit funktioniert Chrome meistens, wenn Sie „wxallowed“ für /usr/local deaktivieren, obwohl es bei einigen Erweiterungen zu Problemen kommen kann (Ghostery ist ein Beispiel). Auf die eine oder andere Weise hofft Theo, dass die vollwertige Arbeit im JITless-Modus in naher Zukunft in einen voll funktionsfähigen Zustand gebracht wird.
Source: opennet.ru