Das unterscheidet SFOP deutlich von klassischen Angriffen wie Return‑Oriented Programming (ROP), die vor allem manipulierte Rücksprungadressen verwenden.
Intel führte Control‑Flow Enforcement Technology (CET) als hardwarebasierte Verteidigung gegen Code‑Reuse‑Angriffe ein. CET kombiniert mehrere Schutzmechanismen, darunter:
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.
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:
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.
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:
So wird die Signalbehandlung selbst zu einem wiederverwendbaren Kontrollfluss‑Primitive innerhalb des Angriffs.
Die Forschung nennt mehrere Ansätze, um SFOP‑artige Angriffe zu erschweren.
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.
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.
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.
Comments
0 comments