SFOP: Neuer Angriff umgeht Intels CET-Schutz auf Linux

Was Segmentation Fault Oriented Programming (SFOP) ist

SFOP ist eine Form eines seriellen Code‑Reuse‑Angriffs. Statt einen Exploit in einem Schritt auszuführen, wird eine kontrollierte Kette von Programmabstürzen erzeugt.

Der Ablauf sieht typischerweise so aus:

• Ein Angreifer provoziert absichtlich einen illegalen Speicherzugriff.
• Das Programm erzeugt daraufhin einen Segmentation Fault (SIGSEGV).
• Linux ruft den registrierten Signal‑Handler für diesen Fehler auf.
• Der Handler bereitet den nächsten kontrollierten Absturz oder Ausführungsschritt vor.

Durch wiederholtes Auslösen solcher Fehler entsteht eine Abfolge von kontrollierten Ausführungsschritten. Jeder Absturz wird Teil einer Angriffskette, die schrittweise Funktionen des bestehenden Programmcodes nutzt.

Das unterscheidet SFOP deutlich von klassischen Angriffen wie Return‑Oriented Programming (ROP), die vor allem manipulierte Rücksprungadressen verwenden.

Warum Intel CET eigentlich davor schützen sollte

Intel führte Control‑Flow Enforcement Technology (CET) als hardwarebasierte Verteidigung gegen Code‑Reuse‑Angriffe ein. CET kombiniert mehrere Schutzmechanismen, darunter:

• Validierung von Rücksprungadressen
• Einschränkungen für indirekte Sprünge

Ziel ist es, zu verhindern, dass Angreifer beliebige Stellen innerhalb eines Programms anspringen und so den Kontrollfluss manipulieren.

Doch CET überwacht primär normale Kontrollflussübergänge innerhalb eines Programms.

Genau hier setzt SFOP an.

Wie SFOP CET auf Linux umgeht

Die entscheidende Beobachtung der Forschenden: Die Zustellung eines Signals ist selbst ein legitimer Kontrollflusswechsel, der vom Betriebssystem durchgeführt wird.

Der Angriff funktioniert vereinfacht so:

1. Ein Exploit zwingt das Zielprogramm zu einem Zugriff auf geschützten Speicher.
2. Linux löst daraufhin einen SIGSEGV‑Signalaufruf aus.
3. Die Ausführung springt zum registrierten Signal‑Handler.
4. Der Handler richtet den nächsten kontrollierten Fehler ein.
5. Der Prozess wiederholt sich mehrfach.

Jeder Signal‑Handler fungiert damit als Baustein einer Angriffskette. Da der Übergang zum Handler durch das Betriebssystem erfolgt, gilt er als legitimer Kontrollfluss und wird von CET nicht blockiert.

Durch diese wiederholten Abstürze können Angreifer Schritt für Schritt Aktionen ausführen, bis schließlich beliebiger Code über vorhandene Programmkomponenten ausgeführt werden kann.

Rolle der Linux‑Signalbehandlung

Programme unter Linux können eigene Handler für Signale wie SIGSEGV registrieren. Solche Handler werden oft verwendet, um Fehler zu protokollieren oder bestimmte Wiederherstellungsmechanismen auszulösen.

SFOP nutzt diese Funktion zweckentfremdet:

• wiederholtes Auslösen von Segmentation Faults
• jedes Mal Aktivierung eines Signal‑Handlers
• kontrollierte Veränderung des Programmzustands

So wird die Signalbehandlung selbst zu einem wiederverwendbaren Kontrollfluss‑Primitive innerhalb des Angriffs.

Vorgeschlagene Gegenmaßnahmen

Die Forschung nennt mehrere Ansätze, um SFOP‑artige Angriffe zu erschweren.

Härtung im Linux‑Kernel

Ein Ansatz besteht darin, die Signalbehandlung im Linux‑Kernel anzupassen, damit wiederholte Segmentation‑Fault‑Sequenzen nicht mehr so leicht als kontrollierte Angriffskette missbraucht werden können.

Öffentliche Berichte erwähnen entsprechende Kernel‑Patches, allerdings sind Details zu Implementierung und Integration derzeit nur begrenzt veröffentlicht.

PLaTypus‑Hardening

Ein weiterer vorgeschlagener Schutzmechanismus heißt PLaTypus.

Dabei handelt es sich um eine zusätzliche Hardening‑Schicht, die speziell darauf abzielt, Schwächen moderner Code‑Reuse‑Abwehrmechanismen zu reduzieren. Der Ansatz beschränkt Kontrollfluss‑Sprünge zwischen verschiedenen Programmbibliotheken.

Die Forschenden stellten fest, dass Angreifer selbst mit aktiviertem CET häufig noch zwischen Funktionen in unterschiedlichen Shared Libraries springen können.

PLaTypus reduziert dieses Risiko, indem es indirekte Sprünge möglichst innerhalb derselben Bibliothek hält und Bibliothekswechsel nur unter strengeren Bedingungen erlaubt. Dadurch sinkt die Zahl möglicher Code‑Reuse‑Ziele drastisch.

Warum diese Forschung wichtig ist

Der SFOP‑Angriff zeigt eine zentrale Herausforderung moderner IT‑Sicherheit:

Hardware‑Schutz allein reicht nicht aus, wenn Betriebssystemmechanismen neue Wege für Angreifer eröffnen.

Selbst ausgefeilte Technologien wie Intel CET können umgangen werden, wenn legitime Systemfunktionen – etwa Signalbehandlung – als neue Kontrollflussbausteine missbraucht werden.

Für Sicherheitsentwickler bedeutet das vor allem eines: Schutzmechanismen müssen über den gesamten Stack hinweg gedacht werden – von CPU‑Features über Betriebssystemdesign bis zur Anwendungsebene. Denn Angreifer suchen immer den schwächsten Punkt in dieser Kette.