SFOP: cómo los fallos de segmentación pueden saltarse la protección Intel CET en Linux

Los procesadores modernos incorporan cada vez más defensas en hardware para frenar los ataques basados en corrupción de memoria. Una de las más importantes en el ecosistema Intel es Control‑Flow Enforcement Technology (CET), diseñada para impedir que los atacantes reutilicen fragmentos de código legítimo para ejecutar acciones maliciosas.

Sin embargo, una investigación reciente demuestra que incluso estas protecciones pueden eludirse cuando interactúan con comportamientos legítimos del sistema operativo. Investigadores del CISPA Helmholtz Center for Information Security presentaron una técnica llamada Segmentation Fault Oriented Programming (SFOP), que aprovecha el manejo de señales de Linux para evadir CET. El trabajo se dio a conocer en el contexto del IEEE Symposium on Security and Privacy 2026.

Qué es Segmentation Fault Oriented Programming (SFOP)

SFOP es un ataque serial de reutilización de código. En lugar de secuestrar directamente el flujo de ejecución del programa, provoca fallos de segmentación repetidos y usa el mecanismo de manejo de señales como un paso intermedio para continuar el ataque.

El proceso típico funciona así:

• El atacante provoca un acceso ilegal a memoria para generar un segmentation fault.
• El sistema Linux envía la señal SIGSEGV al programa.
• Se ejecuta el manejador de señales registrado para ese error.
• Ese manejador prepara el siguiente fallo o el siguiente paso del exploit.

Repitiendo el proceso muchas veces, el atacante puede construir una cadena de ejecución paso a paso usando código existente del programa o de sus bibliotecas.

A diferencia de técnicas conocidas como Return‑Oriented Programming (ROP), que manipulan direcciones de retorno, SFOP utiliza eventos de fallo y manejo de señales como bloques reutilizables para avanzar en la ejecución.

Por qué Intel CET debería impedir este tipo de ataques

Intel introdujo Control‑Flow Enforcement Technology (CET) para combatir precisamente los ataques de reutilización de código.

CET incluye varias protecciones a nivel de hardware, entre ellas:

• validación de direcciones de retorno mediante una shadow stack
• restricciones sobre destinos de saltos indirectos

El objetivo es impedir que un atacante redirija el flujo de ejecución hacia instrucciones inesperadas dentro del propio programa.

En teoría, estas defensas deberían bloquear muchas técnicas como ROP o Jump‑Oriented Programming.

Cómo SFOP logra eludir CET en Linux

La clave del ataque está en un detalle: la entrega de señales por parte del sistema operativo es un cambio de flujo de control completamente legítimo.

SFOP aprovecha ese comportamiento legítimo:

1. El exploit fuerza al programa a acceder a memoria restringida.
2. El sistema genera un SIGSEGV.
3. Linux transfiere la ejecución al manejador de señal registrado.
4. El manejador realiza una acción controlada por el atacante y prepara otro fallo.

Cada vez que ocurre el fallo, el sistema vuelve a transferir el control al manejador. Así se crea una cadena de pasos controlados.

Dado que esta transición de control es gestionada por el sistema operativo y no por un salto indirecto manipulado por el atacante, puede eludir las comprobaciones que CET aplica al flujo normal del programa.

Tras suficientes iteraciones, esta secuencia puede conducir a ejecución arbitraria de código utilizando únicamente componentes ya presentes en el programa o en sus bibliotecas.

El papel del manejo de señales SIGSEGV en Linux

En Linux, las aplicaciones pueden registrar manejadores para señales como SIGSEGV, lo que permite reaccionar ante errores graves —por ejemplo, registrarlos o intentar recuperarse.

SFOP transforma ese mecanismo en una herramienta de explotación:

• provoca fallos de segmentación deliberadamente
• ejecuta un manejador de señal cada vez
• modifica el estado del programa en cada paso

El resultado es que el propio sistema de manejo de señales se convierte en una primitiva de control de flujo reutilizable.

Mitigaciones propuestas

Los investigadores y desarrolladores de seguridad ya han sugerido varias defensas para reducir el riesgo de ataques similares.

Endurecimiento del kernel de Linux

Una de las opciones consiste en modificar el comportamiento del manejo de señales en el kernel de Linux para limitar cómo los atacantes pueden encadenar repetidamente fallos de segmentación y manejadores como parte del flujo de control del exploit. Los informes públicos mencionan la existencia de parches experimentales, aunque los detalles técnicos completos aún son limitados en los resúmenes disponibles.

PLaTypus: capa adicional de protección

Otra defensa propuesta es PLaTypus, una capa de endurecimiento que complementa a CET.

Los investigadores observaron que, incluso con CET activo, los atacantes aún pueden redirigir la ejecución entre distintas bibliotecas compartidas de un programa.

PLaTypus intenta cerrar ese hueco:

• restringe las transiciones indirectas entre bibliotecas
• favorece que los saltos permanezcan dentro de la misma biblioteca
• reduce drásticamente el número de destinos útiles para ataques de reutilización de código

Según los informes, esta estrategia puede reducir los objetivos de control de flujo entre bibliotecas en más de un 98 % con un impacto mínimo en el rendimiento.

Por qué este descubrimiento es importante

El trabajo sobre SFOP subraya una lección clave en la seguridad moderna: las defensas en hardware no son suficientes si otros niveles del sistema siguen ofreciendo primitivas explotables.

Aunque tecnologías como Intel CET elevan mucho el nivel de protección, los atacantes pueden encontrar rutas alternativas aprovechando comportamientos legítimos del sistema operativo, como el manejo de señales.

Para ingenieros de seguridad y desarrolladores de sistemas, el mensaje es claro: la defensa eficaz debe cubrir toda la pila tecnológica, desde el hardware del procesador hasta los mecanismos internos del sistema operativo.