Pläne zur Verstärkung des W^X-Schutzmechanismus in OpenBSD

Theo De Raadt teilte mit seine Pläne zur Verstärkung des W^X (Write XOR Execute)-Schutzmechanismus. Der Kern des Mechanismus besteht darin, dass Speicherseiten eines Prozesses nicht gleichzeitig zum Schreiben und Ausführen zugänglich sein können. Somit kann Code nur ausgeführt werden, nachdem das Schreiben verboten wurde, und das Schreiben auf eine Speicherseite ist nur nach dem Verbot der Ausführung möglich. Der W^X-Mechanismus hilft, Anwendungen im Benutzerspeicher vor typischen Angriffen zu schützen, die durch Pufferüberläufe, einschließlich Stacküberläufen, ausgeführt werden, und er ist in OpenBSD aktiv. standardmäßig.

Von Beginn der Arbeiten an W^X war klar, dass dies ein langer Weg sein würde, da es eine erhebliche Anzahl von Anwendungen gibt, die JIT verwenden. JIT-Implementierungen lassen sich in drei Kategorien unterteilen:

• Wechseln des Speichers zwischen W- und X-Zuständen, wobei die „Kosten“ von Systemaufrufen in Kauf genommen werden. mprotect.
• Erstellen von Aliasen zwischen einem Paar von W- und X-Abbildungen desselben Speichers.
• Die dreckigste Variante - die ein W|X-Speichermodell erfordert, das gleichzeitig Schreiben und Ausführen zulässt.

Derzeit gibt es deutlich weniger Programme, die die dritte Variante verwenden, und mehr, die die erste und zweite verwenden. Dennoch, da es notwendig war, auch Programme mit W|X JIT (hauptsächlich Chromium und Iridum) auszuführen, wurde eine Option zum Einhängen des Dateisystems „wxallowed“ hinzugefügt, die es ermöglichte, Speicher gleichzeitig für Schreiben und Ausführen zu nutzen, wenn die ausführbare ELF-Datei mit dem Marker „wxneeded“ gekennzeichnet ist, während die Anwendungen selbst durch Mechanismen zusätzlich geschützt wurden. pledge und unveil um die Liste der verwendeten Systemaufrufe und die Teile des Dateisystems, die für die Anwendung verfügbar sind, entsprechend einzuschränken.

Um das Ausnutzen von Schwachstellen in solchen Anwendungen weiter zu erschweren, wurde eine Ergänzung des Mechanismus vorgeschlagen MAP_STACK, die überprüft, ob der Systemaufruf aus einer beschreibbaren Speicherseite erfolgt. Wenn die Seite beschreibbar ist, wird der Prozess zwangsweise beendet. Somit kann ein Angreifer keine Systemaufrufe nutzen und wird gezwungen sein, die benötigten Gadgets in der JIT-Implementierung zu finden oder sogar die schwierige Arbeit der Auffindung von Stub-Systemaufrufen direkt innerhalb von zufällig verbundener libc.

Die Prozesse von Chrome/Iridium sind bereits durch pledge und unveil ausreichend geschützt, aber das Verhindern der Nutzung eines systematischen Aufrufs wie write(2) hat eindeutig einige Vorteile, da es dem Angreifer zusätzliche Schwierigkeiten bereitet. Dennoch können auch Schwierigkeiten auftreten, wenn die JIT-Implementierung native Systemaufrufe aus W|X-Speicher verwendet. Es besteht jedoch Grund zur Hoffnung, dass es nicht dazu kommen wird, da sich die ABI mehrfach geändert hat, aber niemand jemals von Problemen berichtet hat.

Die Änderungen sind bereits in den aktuellen Snapshot-Versionen des OpenBSD-Currents verfügbar, und alle Interessierten sind eingeladen, diese zu testen.

Besondere Erwähnung von Theo erhielt die verwandte Nachricht über die Einführung des Modus in Chrome/Iridium JITless. In seinen Augen ist dies für einige Anwendungsmodelle akzeptabel, wahrscheinlich jedoch nicht für alle, da die Belastung der CPU in diesem Modus offensichtlich zunehmen wird. Zurzeit wird Chrome hauptsächlich funktionieren, wenn "wxallowed" für /usr/local deaktiviert ist, obwohl Probleme mit einigen Erweiterungen (beispielsweise ghostery) wahrscheinlich sind. Wie dem auch sei, Theo hofft, dass der vollständige Betrieb im JITless-Modus bald in einen voll funktionsfähigen Zustand gebracht wird.

Quelle: opennet.ru