Integridad del flujo de control

El front-end C/C++ del compilador LLVM, Clang, proporciona varios esquemas "CFI" que funcionan en el borde de avance comprobando errores en tablas virtuales y conversiones de tipo. No todos los esquemas son compatibles con todas las plataformas y la mayoría de ellos, con la excepción de dos esquemas "kcfi" destinados al software de kernel de bajo nivel, dependen de la optimización en tiempo de enlace (LTO) para saber qué funciones deben llamarse en casos normales. ^{[ 15 ]}

También se proporciona una pasada de instrumentación de " pila de llamadas en la sombra " (SCS) independiente que protege el borde posterior comprobando las modificaciones de la pila de llamadas, disponible solo para las arquitecturas ISA aarch64 y RISC-V . Y debido al uso de un registro de procesador compartido , SCS solo es aplicable en ciertas ABI o si de otro modo se garantiza que ningún otro software que utilice el conjunto de registros (hilo/procesador) interfiera con este uso. ^{[ 16 ]}

Google ha distribuido Android con el kernel de Linux compilado por Clang con optimización en tiempo de enlace (LTO) y CFI habilitados desde 2018. ^{[ 17 ]} Aunque SCS está disponible para el kernel de Linux como opción, y también hay soporte disponible para los componentes del sistema de Android, se recomienda habilitarlo solo para componentes para los que se pueda garantizar que no se cargue código de terceros. ^{[ 18 ]}

La colección de compiladores GNU implementó una "pila de llamadas en la sombra" compatible con Clang para aarch64 en la versión 12, publicada en 2022. ^{[ 19 ] [ 20 ]} Esta característica está destinada principalmente a la compilación del kernel de Linux, ya que las bibliotecas de espacio de usuario de GCC no ofrecen soporte para ello. ^{[ 7 ]}

La tecnología de aplicación de control de flujo (CET) de Intel detecta compromisos para controlar la integridad del flujo con una pila de sombra (SS) y seguimiento de bifurcación indirecta (IBT). ^{[ 21 ] [ 22 ]}

El núcleo debe asignar una región de memoria para la pila de sombra que no sea modificable por programas del espacio de usuario, salvo mediante instrucciones especiales. La pila de sombra almacena una copia de la dirección de retorno de cada llamada. En caso de retorno (RET), el procesador comprueba si las direcciones de retorno almacenadas en la pila normal y en la pila de sombra son iguales. Si las direcciones no coinciden, el procesador genera una interrupción INT #21 (Fallo de protección del flujo de control).

El seguimiento de bifurcaciones indirectas detecta instrucciones JMP o CALL indirectas dirigidas a destinos no autorizados. Se implementa añadiendo una nueva máquina de estados interna al procesador. El comportamiento de las instrucciones JMP y CALL indirectas se modifica para que cambien la máquina de estados de IDLE a WAIT_FOR_ENDBRANCH. En el estado WAIT_FOR_ENDBRANCH, la siguiente instrucción a ejecutar debe ser la nueva instrucción ENDBRANCH (ENDBR32 en modo de 32 bits o ENDBR64 en modo de 64 bits), lo que cambia la máquina de estados interna de WAIT_FOR_ENDBRANCH de nuevo a IDLE. Por lo tanto, cada destino autorizado de una instrucción JMP o CALL indirecta debe comenzar con ENDBRANCH. Si el procesador se encuentra en el estado WAIT_FOR_ENDBRANCH (es decir, la instrucción anterior fue una instrucción JMP o CALL indirecta) y la siguiente instrucción no es una instrucción ENDBRANCH, el procesador genera una INT #21 (Fallo de protección del flujo de control). En los procesadores que no admiten el seguimiento de bifurcaciones indirectas CET, las instrucciones ENDBRANCH se interpretan como NOP y no tienen ningún efecto.

Control Flow Guard (CFG) se lanzó por primera vez para Windows 8.1 Update 3 (KB3000850) en noviembre de 2014. Los desarrolladores pueden agregar CFG a sus programas agregando la /guard:cfbandera del enlazador antes de enlazar el programa en Visual Studio 2015 o posterior. ^{[ 23 ]}

A partir de Windows 10 Creators Update (versión 1703 de Windows 10), el kernel de Windows se compila con CFG. ^{[ 24 ]} El kernel de Windows utiliza Hyper-V para evitar que el código malicioso del kernel sobrescriba el mapa de bits CFG. ^{[ 25 ]}

CFG funciona creando un mapa de bits por proceso , donde un bit activado indica que la dirección es un destino válido. Antes de realizar cada llamada a función indirecta, la aplicación comprueba si la dirección de destino está en el mapa de bits. Si la dirección de destino no está en el mapa de bits, el programa finaliza. ^{[ 23 ]} Esto dificulta que un atacante explote una vulnerabilidad de uso después de la liberación reemplazando el contenido de un objeto y luego utilizando una llamada a función indirecta para ejecutar una carga útil. ^{[ 26 ]}

eXtended Flow Guard (XFG) aún no se ha lanzado oficialmente, pero está disponible en la vista previa de Windows Insider y se presentó públicamente en Bluehat Shanghai en 2019. ^{[ 32 ]}

XFG extiende CFG validando las firmas de las llamadas a funciones para asegurar que las llamadas indirectas se realicen únicamente al subconjunto de funciones con la misma firma. La validación de la firma de la llamada a función se implementa agregando instrucciones para almacenar el hash de la función objetivo en el registro r10 inmediatamente antes de la llamada indirecta y almacenar el hash de la función calculado en la memoria inmediatamente anterior al código de la dirección objetivo. Cuando se realiza la llamada indirecta, la función de validación XFG compara el valor en r10 con el hash almacenado de la función objetivo. ^{[ 33 ] [ 34 ]}