PaX Team stellt Schutz vor Code Reuse Exploits vor

Das PaX Team rund um Brad Sprengler hat seine Schutzsoftware RAP (Reuse Attack Protector) fertiggestellt. Das Plug-in für den GCC-Compiler soll bösartige "Quereinsteiger"-Exploits sicher enttarnen. Dazu werden im Kompilat sowohl die Einsprünge in Funktionen als auch die Rücksprungadressen auf nicht erlaubte Ziele überwacht.

Seit Schutzmaßnahmen wie No Execute und Adressenverwürfelung (ASLR) allgemein verbreitet sind, haben sich viele Buffer-Overflow-Exploits dahingehend umorientiert, dass die manipulierten Rücksprünge nicht mehr in den injizierten Schadcode stattfinden, sondern irgendwo mitten hinein in den originalen Programm-Code. Zumeist ist das Sprungziel der Beginn eines Unterprogramms oder einer Funktionen, aber nicht unbedingt.

Kanarienvögel

Diverse Schutzmechanismen sind unter dem Namen Control Flow Integrity (CFI) entwickelt worden, etwa von Microsoft (Control Flow Guard) oder Google (Indirect Function-Call Checks). Diese überwachen aber nur die Einsprünge (forward-edge CFI). Daneben gibt es diverse Stack-Schutz-Mechanismen. IBM etwa hat dafür den Stack Smashing Protector SSP veröffentlicht, Microsoft verwendet beim Visual Studio Compiler mit dem Flag /GS bestimmte Sicherheits-Cookies als sogenannte Kanarienvögel, die auf dem Stack vor der Rücksprungadresse liegen und die ein Überschreiben anzeigen sollen. Diese Techniken haben aber noch Schlupflöcher und/oder sie beeinträchtigen erheblich die Performance.

Der Reduce Attack Protector RAP, den das PaX Team auf dem Hacker 2 Hacker Congress H2HC2015 vorstellte, soll ohne größere Performanceeinbuße mit Hilfe geschickter 64-Bit-Hashes sowohl die erlaubten Einsprünge als auch die Rücksprungadressen überwachen. Eine weitere, allerdings nur der kommerziellen Version vorbehaltene "propabilistische" Schutzfunktion merkt sich zur Laufzeit die jeweilige verschlüsselte Rücksprungadresse in einem speziellen CPU-Register, um so Manipulation auf dem Stack zu erkennen. Die Autoren lassen sich jedoch nicht darüber aus, wie das bei geschachtelten Funktionsaufrufen aussieht. Irgendwo den Key im Speicher abzulegen, entspräche nicht ihrem Worst-Case-Bedrohungs-Szenario, demgemäß dem Angreifer unbeschränkte Speicherzugriffsmöglichkeiten zugebilligt wird.

Wenig Performance-Verlust

Während IBMs "ssp -all" zum Beispiel die Laufzeit von "du -s" um 25 Prozent verlangsamt, soll der RAP-Tribut bei unter 5 Prozent liegen. Auch der SPEC CPU2006-Benchmark Xalancbmk soll nur etwa 4 Prozent an Performance verlieren.

Die öffentliche Version von RAP wird mit dem Test-Kernel 4.5 von grsecurity als Demo mit ausgeliefert. Diese ist aber sehr eingeschränkt: nur 64-bittig, keine C++-Unterstützung, kein propabilistischer Schutz und sie ist vor allem nicht für Userland-Programme lizenziert. Das liege aber nicht an ihnen, meint das PaX Team, sondern an den GPLv2-Lizenz-Ausnahmebedingungen für GCC-Plugins. Die Lizenzgebühren für die unter GPLv3 ausgelieferte kommerzielle Version sind nicht angegeben, die muss man offenbar mit grsecurity.net aushandeln.

update

Hinzuzufügen wäre, dass RAP nicht nur direkte Einsprünge, sondern auch Datenstrukturen mit Funktionszeigern schützt. Auch hierfür wird ein Hash erzeugt, der vor dem Einsprung überprüft wird. Jegliche Manipulationen an solchen Tabellen werden dadurch erkannt und führen sofort zu einer Ausnahmebehandlung (als nicht, wie bei Microsofts Kernel Patch Protection, erst nach einer gewissen Zeit).

Zum Thema verschachtelte Aufrufe haben sich die Autoren auf S. 14 im H2HC-Paper ausgelassen. Der Key verbleibt dabei immer in einem reservierten CPU-Register (R12 bei x86). Die verschlüsselte Rücksprungadresse kommt auf den Stack. (as)