Habilitación de la protección de pila forzada por hardware (cetcompat) en Chrome


Chrome 90 para Windows adopta la protección de pila reforzada por hardware, una tecnología de mitigación para dificultar la explotación de los errores de seguridad para los atacantes. Esto es compatible con Windows 20H1 (actualización de diciembre) o posterior, que se ejecuta en procesadores con tecnología Control-flow Enforcement Technology (CET) como las CPU Intel 11th Gen o AMD Zen 3. Con esta mitigación, el procesador mantiene una pila nueva y protegida de direcciones de retorno válidas (una pila oculta). Esto mejora la seguridad al hacer que las vulnerabilidades sean más difíciles de escribir. Sin embargo, puede afectar la estabilidad si el software que se carga en Chrome no es compatible con la mitigación. A continuación, describimos algunas técnicas de explotación que son mitigadas por la protección de pila, discutimos sus limitaciones y qué haremos a continuación para abordarlas. Finalmente, proporcionamos algunos consejos rápidos para otros autores de software a medida que habilitan / cetcompat para sus aplicaciones de Windows.

Protección de la pila

Imagine un error simple de uso después de la liberación (UAF) en el que un atacante puede inducir a un programa a llamar a un puntero de su elección. En este caso, el atacante controla un objeto que ocupa un espacio utilizado anteriormente por otro objeto, que el programa continúa utilizando erróneamente. El atacante establece un campo en esta región que se utiliza como una llamada de función a la dirección del código que el atacante quisiera ejecutar. Hace años, un atacante podía simplemente escribir su código de shell en una ubicación conocida y luego, en su sobrescritura, establecer el puntero de instrucción en este código de shell. Con el tiempo, se agregó la Prevención de ejecución de datos para evitar que las pilas o montones sean ejecutables.

En respuesta, los atacantes inventaron la programación orientada al retorno (ROP). Aquí, los atacantes aprovechan el propio código del proceso, ya que debe ser ejecutable. Con el control de la pila (ya sea para escribir valores allí o cambiando el puntero de la pila) y el control del puntero de la instrucción, un atacante puede usar la instrucción `ret` para saltar a un código diferente y útil.

Durante un intento de explotación, el puntero de la instrucción se cambia para que, en lugar de su destino normal, se invoque un pequeño fragmento de código, llamado dispositivo ROP. Estos gadgets se seleccionan para que hagan algo útil (como preparar un registro para una llamada de función) y luego llamar a return.

Estos diminutos fragmentos no tienen por qué ser una función completa en el programa normal, e incluso podrían encontrarse a mitad de camino a través de una instrucción legítima. Al alinear el conjunto correcto de direcciones de "devolución", se puede llamar a una cadena de estos gadgets, y el "ret" de cada gadget cambia al siguiente. Con un poco de paciencia, o con las herramientas adecuadas, un atacante puede juntar los argumentos de una llamada a una función y luego realmente llamar a la función.

Chrome tiene un arquitectura multiproceso – un proceso del navegador principal actúa como el usuario que ha iniciado sesión y genera procesos de utilidad y renderizado restringidos para alojar el código del sitio web. Este aislamiento reduce la gravedad de un error en un renderizador, ya que su proceso no puede hacer mucho por sí mismo. Luego, los atacantes intentarán usar otro error de escape de la zona de pruebas para ejecutar código en el navegador, lo que les permite actuar como el usuario que inició sesión. Como Windows asigna las bibliotecas en la misma dirección en diferentes procesos, cualquier error que permita a un atacante leer la memoria es suficiente para que examine el binario de Chrome y las bibliotecas cargadas en busca de dispositivos ROP. Esto hace que la prevención de cadenas ROP en el proceso del navegador sea especialmente útil como mitigación.

Ingrese a la protección de la pila. Junto con la pila existente, la CPU mantiene una pila de sombra. Esta pila no puede ser manipulada directamente por código de programa normal y solo almacena direcciones de retorno. La instrucción CALL se modifica para enviar una dirección de retorno (la instrucción después de CALL) tanto a la pila normal como a la pila de sombra. La instrucción RET (retorno) todavía toma su dirección de retorno de la pila normal, pero ahora verifica que sea la misma que la almacenada en la región de la pila de sombras. Si es así, el programa se deja solo y continúa funcionando como siempre. Si las direcciones no coinciden, se genera una excepción que es interceptada por el sistema operativo (no por Chrome). El sistema operativo tiene la oportunidad de modificar la región de sombra y permitir que el programa continúe, pero en la mayoría de los casos una falta de coincidencia de direcciones es el resultado de un error del programa, por lo que el programa se termina inmediatamente.

En nuestro ejemplo anterior, el atacante podrá realizar su salto inicial a un dispositivo ROP, pero al intentar volver al siguiente dispositivo será detenido.

Algunos programas pueden ser incompatibles con este mecanismo, especialmente algunos programas de seguridad más antiguos que se inyectan en un proceso y enganchan las funciones del sistema operativo sobrescribiendo el preludio con `rax = & hook; empujar rax; ret`.

Limitaciones

Chrome aún no admite todas las direcciones de aplicación del flujo de control. La protección de pila aplica el borde inverso del gráfico de llamadas pero no limita el borde de avance. Aún será posible realizar saltos indirectos alrededor del código existente, ya que la protección de la pila solo se valida cuando se encuentra una instrucción de retorno y los destinos de llamada no se validan. En Windows, se puede utilizar una tecnología llamada Control Flow Guard (CFG) para verificar el destino de una llamada de función indirecta antes de intentarlo. Esto evita llamar a la mitad de una función, lo que reduce significativamente el alcance de las instrucciones útiles que pueden utilizar los atacantes. El CET de Intel proporciona otro enfoque, que incluye una instrucción ENDBRANCH para evitar saltos a ubicaciones de códigos arbitrarios. Se pueden utilizar herramientas de etiquetado de memoria como MTE para dificultar la modificación de punteros a secuencias de código válidas (y hace que los UAF sean más difíciles en general). Somos trabajando para presentar CFG a Chrome para Windows, y agregará otras técnicas con el tiempo.

Por sí misma, la protección de la pila se puede omitir en algunos contextos. Por ejemplo, la protección de pila no evita que un atacante engañe a un programa para que llame a una función existente reemplazando por completo un objeto que contiene un puntero de función. Este enfoque no involucra ROP ya que la llamada a la función ocurre en lugar de la llamada esperada y regresa a la dirección desde la que se llamó originalmente, por lo que debe permitirse. Sin embargo, la función llamada debe ser útil para un atacante y la mayoría de las funciones no lo serán. Un ejemplo de un ataque que usa este método es crear una llamada para agregar el argumento `–no-sandbox` a la línea de comandos de Chrome. Esto da como resultado que los renderizadores futuros se lancen sin las protecciones normales. Con el tiempo identificaremos y retirar herramientas tan útiles.

En el renderizador, por razones de rendimiento, nuestros motores javascript y wasm pueden usar memoria que se puede escribir y ejecutar al mismo tiempo. Esto permite que un atacante modifique el código que la v8 ya va a ejecutar, ahorrándole la molestia de construir una cadena ROP. Esto explica por qué no era nuestra primera prioridad hacer compatible v8 CET y por qué la protección de pila aún no está habilitada en el renderizador.

Finalmente, la protección de la pila no detiene los errores en primer lugar. Todo lo que hemos discutido anteriormente es una mitigación que dificulta la ejecución de código arbitrario. Si un error de programación permite escrituras arbitrarias, es muy poco probable que podamos evitar que se utilice para ejecutar código arbitrario. Los atacantes se adaptarán y encontrarán nuevas formas de convertir los errores de seguridad de la memoria en ejecución de código.

Consejos de depuración

Puede ver si la Protección de pila aplicada por hardware está habilitada para un proceso mediante el Administrador de tareas de Windows. Abra el administrador de tareas, abra la pestaña Detalles, haga clic con el botón derecho en un encabezado, seleccione columnas y marque la casilla Protección de pila aplicada por hardware. La pantalla del proceso indicará entonces si un proceso está inscrito en esta mitigación. "Solo módulos compatibles" indica que cualquier dll marcado como / cetcompat en el momento de la compilación generará una excepción si una dirección de retorno no es válida.

Puede ver qué procesos de Chrome están excluidos de CET consultando el campo Mitigaciones de chrome: // sandbox y haciendo clic en "+". Todos los procesos están incluidos a menos que la mitigación CET_USER_SHADOW_STACKS_ALWAYS_OFF esté presente en la vista de detalles expandida.

Si está desarrollando software o depurando un problema en Chrome, la pila de sombra puede ser útil ya que solo incluye direcciones de retorno, y estas no pueden ser corrompidas por escrituras no autorizadas en otras partes del proceso. Para ver estos registros use el comando `r` en windbg con la opción de máscara:

0: 159> rM 8002

rax = 00000000c000060a rbx = 000000fa5bbfeff0 rcx = 0000000000000030

rdx = 0000000000000000 rsi = 00007ffba4118924 rdi = 000000fa5bbff1a0

rip = 00007ffc1847b4a1 rsp = 000000fa5bbfc0a0 rbp = 000000fa5bbfc0a0

r8 = 000000fa5bbfc098 r9 = 0000000000000000 r10 = 0000000000000000

r11 = 0000000000000246 r12 = 000000fa5bbfe230 r13 = 000002c3450b5830

r14 = 000002c3450b7850 r15 = 000000fa5bbfc260

iopl = 0 nv arriba ei pl zr na po nc

ssp = 000000fa5c3fef10 cetumsr = 0000000000000001

`ssp` apunta a la región de la pila de sombras,` cetumsr` indica si cet está habilitado para el proceso.

Luego puede ver la pila de llamadas dentro de la región de sombra usando `dps @ ssp`. Los valores no se sobrescriben, por lo que también puede ver de dónde viene si mira un poco más a fondo: `dps @ ssp-20`.

Si un proceso no es compatible con la protección de pila aplicada por hardware, el registro de eventos del sistema (registro de la aplicación) incluirá breves informes de error (Id: 1001). Puede filtrar los relacionados con cetcompat utilizando el siguiente fragmento de PowerShell: –

Get-WinEvent -MaxEvents 128 -FilterHashtable @ LogName = 'Aplicación'; Id = '1001' `

| Where-Object $ _. Message -match 'chrome.exe' `

| Seleccionar-Objeto -Primeros 8 '

| Florida

Estos incluirán los siguientes parámetros: –

P1: application.exe

P2: versión de la aplicación

P3: desarrollo de aplicaciones de la aplicación

P4: módulo con fallas .dll

P5: versión del módulo con fallas

P6: módulo con fallas build ts

P7: desplazamiento de fallas en P4 desde base_address

P8: código de excepción (c0000409)

P9: subcódigo (00 … 000030)

Si Chrome se está comportando mal y cree que podría deberse a cetcompat, es posible deshabilitarlo usando las Opciones de ejecución de archivos de imagen; no recomendamos esto excepto por un período limitado de prueba. Si descubre que tiene que hacer esto, plantee un problema en https://crbug.com para que podamos investigar el error.

Otras lecturas

Resumen

/ cetcompat está habilitado para la mayoría de los procesos para Chrome M90 ​​en Windows. Habilitar la protección de pila aplicada por hardware se combinará con las medidas existentes y futuras para hacer que la explotación sea más difícil y, por lo tanto, más costosa para un atacante, y en última instancia protegerá a las personas que usan Chrome todos los días.



Enlace a la noticia original