PLaTypus härtet Intel CET gegen moderne Code-Reuse-Angriffe

CET soll sogenannte Code-Reuse-Angriffe erschweren, bei denen Angreifer vorhandenen Programmcode missbrauchen, um Systeme zu kompromittieren. Forscher zeigen jedoch, dass es weiter möglich ist, zwischen Programmbibliotheken zu wechseln und so die Schutzmechanismen zu umgehen. PLaTypus schränkt genau diese Bewegungsfreiheit ein. Entwickelt wurde die zusätzliche Sicherheitsschicht von Apostolos Chatzianagnostou und Marcos Bajo aus dem Team von CISPA-Faculty Prof. Dr. Christian Rossow.

Code-Reuse-Angriffe sind seit über zwei Jahrzehnten eine Bedrohung für die Sicherheit von Software. Statt eigenen Schadcode einzuschleusen, missbrauchen Angreifer dabei bereits vorhandene Programmteile. Grundlage sind meist sogenannte Memory-Corruption-Schwachstellen, etwa Buffer Overflows oder Use-after-free-Fehler in C- oder C++-Software. „Solche Schwachstellen finden sich unter anderem in Webservern, Browsern oder VPN-Systemen. Gelingt ein Angriff, können Angreifer beispielsweise sensible Daten auslesen, Schadsoftware installieren oder die vollständige Kontrolle über Systeme übernehmen“, erklärt CISPA-Forscher Apostolos Chatzianagnostou.

PLaTypus beschränkt beliebige Wechsel zwischen Bibliotheken

Um Code-Reuse-Angriffe zu erschweren, setzen moderne Prozessoren zunehmend auf hardwaregestützte Schutzmechanismen wie zum Beispiel Intel CET oder ARM Branch Target Identification (BTI). Sie sollen verhindern, dass Angreifer den Kontrollfluss eines Programms durch manipulierte Sprung- oder Rücksprungadressen auf nicht vorgesehene Codebereiche umlenken können. 

„Schutzmechanismen wie CET oder BTI werden in den kommenden Jahren voraussichtlich zum Standard moderner Systeme gehören. Wir haben jedoch festgestellt, dass sie weiterhin einen wichtigen Angriffsweg offenlassen: Angreifer können nach wie vor beliebig zwischen Funktionen unterschiedlicher Bibliotheken springen“, so Apostolos Chatzianagnostou.

Die zusätzliche Härtungsschicht PLaTypus setzt genau hier an. Sie sorgt dafür, dass indirekte Sprünge möglichst innerhalb derselben Programmbibliothek bleiben. Übergänge zwischen verschiedenen Bibliotheken sind nur über ausdrücklich vorgesehene Mechanismen, insbesondere PLT-Stubs erlaubt. Das sind kleine Sprungstellen, die Linux-Systeme ohnehin nutzen, um Aufrufe externer Funktionen zur Laufzeit aufzulösen. 

So soll verhindert werden, dass Angreifer kompromittierte Funktionszeiger nutzen, um beliebige Funktionen in anderen Bibliotheken anzuspringen. „Unsere zentrale Motivation war einfach: Wenn ein Modul nicht ausdrücklich Zugriff auf eine Funktion benötigt, sollte es diese auch nicht indirekt anspringen können“, so Apostolos Chatzianagnostou.

Praxisnah statt theoretisch

Im Unterschied zu vielen akademischen Sicherheitsansätzen setzt PLaTypus bewusst auf einen praxisnahen Ansatz. Statt bestehende Schutzmechanismen zu ersetzen, ergänzt die Mitigation vorhandene Sicherheitsfunktionen und nutzt bereits etablierte Mechanismen moderner Betriebssysteme. Dadurch bleibt der zusätzliche Laufzeitaufwand gering und die Integration in bestehende Software realistischer.

Nach Angaben der Forscher reduziert PLaTypus die Zahl indirekt erreichbarer Funktionen zwischen Bibliotheken um mehr als 98 Prozent. In Tests mit Anwendungen wie Nginx oder Redis habe der Ansatz zugleich weniger als 0,5 Prozent zusätzliche Laufzeitkosten verursacht. „Unser Prototyp ist derzeit für die Intel-Architektur implementiert, der Ansatz könnte jedoch auch in ARM-Systemen funktionieren“, sagt Apostolos Chatzianagnostou.

Von der Forschung in reale Toolchains

Noch ist PLaTypus ein Forschungsprototyp. Die Forscher stehen jedoch bereits mit der LLVM-Community im Austausch, um mögliche Wege für eine Integration in die reguläre LLVM-Toolchain. Da PLaTypus als Compiler-basierte Mitigation auf LLVM aufsetzt, wäre eine solche Integration ein wichtiger Schritt hin zu einem praktischen Einsatz. „Der Weg von akademischen Sicherheitsansätzen in reale Entwicklungswerkzeuge ist komplex und nur in enger Zusammenarbeit mit der Community, in unserem Fall mit den LLVM-Entwicklern, möglich. Ich würde mich freuen, wenn wir das in einem gemeinsamen Projekt realisieren könnten“, erklärt Apostolos Chatzianagnostou.