SFOP : comment des chercheurs ont contourné Intel CET sur Linux en exploitant les segmentation faults

En répétant ce processus, l’attaque progresse étape par étape, chaque crash devenant un maillon d’une chaîne d’exécution contrôlée. L’attaquant peut ainsi exploiter du code déjà présent dans le programme ou ses bibliothèques pour accomplir des actions choisies.

Contrairement aux techniques classiques comme le Return‑Oriented Programming (ROP), qui manipulent les adresses de retour sur la pile, SFOP avance grâce à une succession de gestionnaires de fautes déclenchés volontairement.

Pourquoi Intel CET était censé empêcher ce type d’attaque

Intel a introduit Control‑Flow Enforcement Technology (CET) pour limiter les attaques de réutilisation de code. Cette protection matérielle combine plusieurs mécanismes, notamment la vérification des adresses de retour et le contrôle des cibles de branches indirectes.

L’objectif est d’empêcher un attaquant de détourner l’exécution vers des instructions imprévues au sein du programme.

Cependant, CET protège surtout contre les transferts de contrôle illégitimes à l’intérieur du flux normal d’un programme.

SFOP contourne ce modèle en utilisant un comportement parfaitement légitime du système d’exploitation : la livraison d’un signal après une faute mémoire.

Comment SFOP contourne CET sur Linux

L’idée centrale est que la livraison d’un signal est un transfert de contrôle valide orchestré par le noyau Linux.

Le déroulement simplifié est le suivant :

1. L’attaque force le programme à accéder à une zone mémoire interdite.
2. Linux déclenche alors un signal SIGSEGV.
3. L’exécution est redirigée vers le gestionnaire de signal enregistré.
4. Ce gestionnaire prépare ou provoque la prochaine faute.

Chaque gestionnaire devient ainsi une étape dans une chaîne d’exécution contrôlée par l’attaquant.

Comme cette transition vers le gestionnaire est une opération légitime gérée par le système d’exploitation, elle peut contourner certaines vérifications que CET applique normalement aux retours de fonctions et aux branches indirectes.

À force de répéter ces cycles de crash et de gestion de signal, l’attaquant peut assembler un comportement complexe et atteindre l’exécution de code arbitraire en réutilisant des composants existants du programme.

Le rôle du mécanisme SIGSEGV dans Linux

Sous Linux, un programme peut enregistrer un gestionnaire pour des signaux comme SIGSEGV, qui correspond à une erreur d’accès mémoire.

Ces gestionnaires sont généralement utilisés pour :

• journaliser une erreur,
• tenter une récupération,
• ou effectuer un arrêt contrôlé.

SFOP détourne ce mécanisme en :

• provoquant volontairement des segmentation faults,
• déclenchant le gestionnaire à chaque fois,
• modifiant la logique exécutée à chaque étape.

Le système de gestion des signaux devient alors un bloc de construction réutilisable pour manipuler le flux d’exécution.

Mesures de défense proposées

Les chercheurs ont également évoqué plusieurs pistes pour limiter ce type d’attaque.

Durcissement du noyau Linux

Une première approche consiste à modifier le comportement de gestion des signaux dans le noyau Linux afin d’empêcher l’utilisation répétée des segmentation faults comme primitives de contrôle de flux.

Des correctifs au niveau du noyau sont mentionnés dans les résumés publics des travaux, même si les détails techniques précis restent encore limités dans les informations disponibles.

PLaTypus : une couche de protection supplémentaire

Une autre proposition est PLaTypus, une couche de durcissement destinée à renforcer CET face aux techniques modernes de réutilisation de code.

Les chercheurs ont observé qu’un attaquant peut toujours détourner l’exécution entre différentes bibliothèques partagées même lorsque CET est actif.

PLaTypus répond à ce problème en restreignant les transitions indirectes :

• les sauts indirects doivent rester autant que possible dans la même bibliothèque ;
• les transitions vers d’autres bibliothèques sont strictement contrôlées.

Cette stratégie réduit drastiquement le nombre de cibles exploitables pour les attaques de type code‑reuse, diminuant ainsi fortement la surface d’attaque.

Pourquoi cette découverte est importante

La recherche autour de SFOP rappelle une réalité bien connue en sécurité informatique : les protections matérielles ne suffisent pas si les mécanismes du système d’exploitation peuvent servir de primitives exploitables.

Même des protections avancées comme Intel CET peuvent être contournées lorsque des comportements légitimes — ici la gestion des signaux — permettent de reconstruire une chaîne d’exécution contrôlée.

Pour les ingénieurs sécurité et les développeurs systèmes, la leçon est claire : la défense doit être pensée sur l’ensemble de la pile logicielle et matérielle, du processeur jusqu’aux mécanismes internes du système d’exploitation.