Microsoft y Intel desarrollan una nueva tecnología para proteger el flujo de control en programas

Arreglar los errores individuales detrás de las vulnerabilidades que los hackers utilizan para atacar sistemas es importante, pero es mucho más efectivo bloquear las técnicas que los atacantes utilizan para explotar esas vulnerabilidades y eliminar una clase completa de exploits, o al menos hacer que sean más costosos y demorados crearlos.

¿Qué es la programación orientada a retornos (ROP)?

La programación orientada a retornos (ROP) ha sido una técnica muy común y especialmente difícil de bloquear, ya que en lugar de intentar inyectar su propio código en procesos en ejecución (algo a lo que los sistemas operativos y navegadores han estado añadiendo defensas), los atacantes buscan fragmentos pequeños del código legítimo que ya se encuentra en la memoria y que contienen "retornos" - donde el código salta hacia adelante a una nueva rutina o vuelve al hilo principal.

"Con ROP, no puedo crear código nuevo; solo puedo saltar entre diferentes piezas de código e intentar unir eso en una carga útil", dijo Dave Weston, director de seguridad de SO de Microsoft a Newsmatic. Si el código legítimo tiene un error de seguridad de memoria, como un desbordamiento de búfer, corromper esos punteros en memoria significa que el sistema comienza a ejecutar el propio código del atacante en lugar de volver a la dirección en la pila de llamadas del programa.

Microsoft ha estado trabajando en formas de detener a los atacantes de secuestrar el flujo de control en programas como este desde aproximadamente 2012. Windows ha agregado múltiples niveles de protección, comenzando por la firma de código importante (Code Integrity Guard, o CIG) y bloqueando la generación de código en tiempo de ejecución primero en el navegador y luego en las máquinas virtuales y en el kernel (Arbitrary Code Guard, o ACG).

"El objetivo es evitar que el atacante cargue un binario que Microsoft o alguno de nuestros terceros no haya firmado; incluso si pueden explotar el proceso y obtener corrupción de memoria en el proceso, no pueden inyectar shellcode u otros constructos", explicó Weston.

El avance hacia la protección del flujo de control

La defensa anterior fue lo suficientemente efectiva como para obligar a los atacantes a utilizar ROP, por lo que el siguiente paso fue tratar de proteger el flujo de control dentro del programa. La integridad del flujo de control llegó a Windows 8.1 como Control Flow Guard (CFG). Esto bloquea los ataques de flujo de control hacia adelante (donde el código sale o realiza una llamada y los atacantes intentan enviarlo al lugar equivocado).

Los mejores VPN para pequeñas empresas: ExpressVPN

"En tiempo de compilación, tomamos un registro de todas las transferencias o saltos directos o llamadas indirectas que el desarrollador de software pretende que el código realice, y ese mapa se pasa al kernel cuando se carga el binario y se hace cumplir cuando se ejecuta el código", dijo Weston. Si un atacante logra enviar el código a una dirección que no está en el mapa, el proceso se termina: una aplicación infectada se bloqueará, pero no ejecutará el código malicioso.

CFG es la razón por la que varios ataques zero-day importantes en Windows 7 no afectaron a Windows 10. Sin embargo, como señaló Weston, 2015 es hace mucho tiempo en términos de seguridad, y CFG solo aborda parte del problema. "Los atacantes realmente han comenzado a corromper la pila, inyectando sus marcos ROP o sus conjuntos de instrucciones maliciosas". Al interferir con el flujo de ejecución cuando vuelve al hilo principal en lugar de cuando salta hacia adelante, pueden eludir CFG y ejecutar su propio código cuando el hilo debería regresar.

Llamada y retorno

No es que Microsoft no supiera que eso podría suceder; simplemente es más difícil de proteger y la mejor opción es hacerlo en hardware, con un registro especial en la CPU que guarda una copia de la dirección de retorno donde no se puede manipular. Cuando se ejecuta el fragmento de código con la instrucción de retorno, puede comparar la dirección en la pila de llamadas en la memoria con la dirección en la "sombra" de la pila almacenada en el procesador para verificar que no se haya alterado.

Diseñar nuevas instrucciones de CPU lleva tiempo, e incluso una vez que se lanzan, lleva un tiempo antes de que las personas compren nuevo hardware, por lo que Microsoft intentó crear una pila sombra en software. (Este no fue el primer intento de crear una pila sombra; hay uno implementado en CLANG que Chrome utilizó durante un tiempo). De manera inusual, el enfoque que se habría convertido en Return Flow Guard no fue diseñado por los ingenieros de software habituales, sino por el equipo rojo de Windows, el grupo que ataca las compilaciones internas y las filtraciones de Windows para buscar vulnerabilidades. Pero cuando el mismo equipo analizó cómo podrían atacar su propio diseño, encontraron una condición de carrera que significaba que algunas aplicaciones no estaban protegidas y decidieron no lanzarla en absoluto.

"El desafío de hacer una pila sombra en software es que tienes dos opciones: puedes intentar ocultarlo o puedes intentar ubicarlo en un lugar donde el atacante no pueda escribir, y al final eso depende de si puedes modificar la tabla de páginas o si puedes ubicarlo en la memoria si las cosas van mal", explicó Weston. "Intentamos ocultarlo en algún lugar en la memoria de 64 bits envolviéndolo en páginas de protección, para que si alguien hiciera una búsqueda iterativa en la memoria, encontrara primero un espacio de protección y bloqueara el proceso antes de encontrar la pila sombra". Pero en aplicaciones multihilo de alto rendimiento, los atacantes a veces podían hacer que el kernel omitiera la comprobación para ver si la dirección de retorno coincidía con la dirección en la pila sombra.

"Cuando tenemos que hacerlo en software, tenemos que introducir 'no ops'; cuando ingresas y sales de la función, las rellenamos con espacios en blanco, por lo que las personas pueden manipular la memoria, pueden manipular las condiciones de carrera del sistema y saltarse por completo las comprobaciones", explicó Hari Pulapaka, gerente de programa principal del equipo de kernel de Windows. No hay condición de carrera cuando la pila sombra se guarda en hardware, por lo que las comprobaciones no se saltan.

Protección cibernética: ahorrar $682K en tu empresa

Microsoft e Intel trabajaron juntos en un diseño llamado Control-flow Enforcement Technology (CET) hace varios años, que agrega el nuevo registro de puntero de pila sombra (SSP) y modifica las instrucciones de llamada y retorno estándar de la CPU para almacenar una copia de la dirección de retorno y compararla con la que se encuentra en la memoria; por lo que la mayoría de los programas no necesitarán cambios para ser compatibles. Si las dos direcciones no coinciden, lo que significa que la pila ha sido interferida, el código dejará de ejecutarse.

"La tabla de páginas de sombra se asigna en un lugar al que la mayoría de los procesos o incluso el kernel no pueden acceder, y esto está respaldado por un nuevo atributo de tabla de páginas que ni siquiera se ha expuesto todavía y las personas no pueden consultar tampoco", dijo Pulapaka. "La idea es que no podrás ver que existe y no podrás tocarlo, y si intentas tocarlo, el kernel no permitirá que ningún proceso arbitrario lo toque".

CET también incluye alguna protección de llamada directa hacia adelante: el seguimiento de la rama indirecta realiza una comprobación similar a la de CFG, pero en hardware. La especificación CET se lanzó por primera vez en 2016 y, por motivos de compatibilidad, el silicio lanzado desde entonces ha tenido una versión no funcional de la instrucción que marca las direcciones de la rama indirecta como seguras.

Intel confirmó que CET se incluirá en las CPUs de Tiger Lake este año y en la próxima generación de Xeon para servidores. AMD no dio una fecha, pero nos dijo que tendrá el equivalente a CET pronto. Arm está adoptando un enfoque diferente, utilizando punteros firmados.

Compatible y seguro

Microsoft ya ha comenzado a incorporar el soporte en Windows 10, comenzando por la versión 1903 y completándola en la próxima versión 2004, por lo que ha estado apareciendo en compilaciones internas de anillo rápido. No está activado porque el hardware aún no está ampliamente disponible, pero está allí para probar la compatibilidad, explicó Pulapaka. "Cuando una compilación interna tiene todas estas comprobaciones en el kernel, nos da confianza en que no hemos roto nada ni hemos causado errores".

9 desafíos clave que enfrentan las empresas con el trabajo remoto durante la pandemia de COVID-19

Para evitar problemas de compatibilidad con software de terceros, la protección de la pila CET será inicialmente una opción en Windows. Los desarrolladores pueden hacer esto estableciendo un atributo en una aplicación o DLL con un indicador de enlace para marcarla como compatible con CET. Esto se ha hecho para todo el código y las bibliotecas de Windows y, explicó Pulapaka, "si alguien intenta atacar el código de Windows y tropezamos con los sistemas de protección de CET, deberíamos bloquear el proceso".

Si no establecen ese bit, CET no entrará en acción, e incluso si los desarrolladores establecen el bit para su propio código, si llaman a un marco o biblioteca de terceros que no tiene el indicador CET establecido y este se bloquea porque no pasa la comprobación de dirección CET, Windows no detendrá la aplicación original.

"Estamos siendo un poco conservadores para evitar romper aplicaciones", dijo Pulapaka. Pero Windows también podría ejecutarse en un modo estricto. "Si una aplicación dice que es compatible con CET, incluso si el DLL de terceros que carga no es compatible con CET, en ese modo haríamos todas las comprobaciones en ese DLL y bloquearíamos el proceso si alguien intenta atacarlo".

Microsoft aún no ha decidido cómo se aplicaría ese modo porque los desarrolladores y las empresas no tienen el hardware adecuado para probar las aplicaciones. "Queremos brindar flexibilidad a todos, queremos que la aplicación tome la decisión de la política, queremos que la empresa tome la decisión de la política y queremos que Microsoft también tome la decisión de la política", dijo Pulapaka. "Creo que es demasiado pronto para decir qué activaríamos o desactivaríamos o forzaríamos de manera predeterminada, porque aún no tenemos el hardware".

Pulapaka espera que los problemas de compatibilidad con CET sean raros, pero dado el tamaño del ecosistema de Windows, es posible que algunas aplicaciones encuentren problemas. Esas son las más propensas a ser herramientas sofisticadas como depuradores, herramientas de generación de código JIT, DRM o motores de detección de trampas para juegos, que dependen de un código de ensamblaje de bajo nivel.

"Si tienen algún código extraño que intente manipular los punteros de la pila, podrían tropezar. Es por eso que queremos comenzar con este enfoque más conservador y ver cómo va; probablemente el 99% del mundo del software no tendría que preocuparse de si sus aplicaciones necesitan alguna prueba especial adicional con CET".

El trabajo desde casa durante la pandemia de COVID-19 aumenta los riesgos de brechas de datos

Cuando los desarrolladores y las empresas tengan el hardware adecuado para probar y deseen adoptar CET, pueden configurar el archivo de enlace en Visual Studio y utilizar la misma herramienta de análisis binario que Microsoft utiliza para escanear cada compilación de Windows y asegurarse de que el indicador CET esté establecido en todo el código.

Proteger el flujo de código en hardware es la mejor opción para la seguridad y debería ser mejor para el rendimiento que agregar comprobaciones en Windows. Hasta que esté disponible Tiger Lake, es imposible proporcionar cifras reales, pero "sin duda será mucho mejor que hacerlo en software porque, por definición, hacerlo en hardware es mucho más rápido", dijo Pulapaka a Newsmatic.

Esto es importante porque la pila sombra es una protección importante que hemos estado esperando durante varios años para completar la lista de las cuatro protecciones de código de Microsoft.

"Estas cosas solo son realmente efectivas cuando se combinan", señaló Weston, "pero cuando esas protecciones se combinan, mitigamos la mayoría de las técnicas que vemos hoy en día en la naturaleza. Cuando se trata del panorama x86, creemos que CET posiblemente sea la mitigación más importante que se ha implementado para la corrupción de memoria y los exploits zero-day en los últimos años".

Como siempre, mejorar la protección en un área lleva a los atacantes a cambiar de técnicas, pero esto sigue siendo un gran avance.

"La corrupción de datos está emergiendo como el camino futuro para los atacantes: sabemos internamente que se puede escribir un exploit que elude las cuatro protecciones con pura corrupción de datos", dijo Weston. "Eso no significa que CET no sea increíblemente valioso, porque eso es un poco como una cirugía a corazón abierto y va a ser realmente disruptivo para los atacantes, pero ya nos estamos moviendo hacia un mundo posterior a las cuatro protecciones en el que hemos comenzado a pensar en el próximo conjunto de desafíos en torno a la corrupción de datos".

Las mejores certificaciones de ciberseguridad para impulsar tu carrera profesional

Recursos adicionales

• Seguridad de Windows 10: una guía para líderes empresariales (Newsmatic Premium)
• Cómo activar y utilizar la función de copia de seguridad incorporada de Windows 10 (Newsmatic)
• Cómo aumentar la velocidad de apagado en Windows 10 (Newsmatic)
• Cómo optimizar la configuración de energía de Windows 10 para obtener un mayor rendimiento (Newsmatic)
• Guía gratuita de soporte técnico y solución de problemas de Windows 10 (ZDNet)
• Obtén más consejos y noticias de Microsoft imprescindibles (Newsmatic en Flipboard)

En Newsmatic nos especializamos en tecnología de vanguardia, contamos con los artículos mas novedosos sobre Seguridad, allí encontraras muchos artículos similares a Microsoft y Intel desarrollan una nueva tecnología para proteger el flujo de control en programas , tenemos lo ultimo en tecnología 2023.