Descubre cómo la vulnerabilidad de la CPU GhostRace amenaza todas las arquitecturas principales según investigadores de IBM y VU Amsterdam. Este nuevo ataque de ejecución especulativa multiplataforma expone riesgos para contraseñas y datos sensibles. En un anuncio realizado el 12 de marzo en Twitter, investigadores de VUSec e IBM revelaron públicamente esta preocupante vulnerabilidad, vinculando al documento de divulgación alojado por VUSec.

Las condiciones de carrera surgen cuando múltiples hilos intentan acceder a un recurso compartido sin una sincronización adecuada, lo que a menudo conduce a vulnerabilidades como el uso después de liberar de forma concurrente. Para mitigar su ocurrencia, los sistemas operativos confían en primitivas de sincronización como mutex, spinlocks, etc.

En este trabajo, presentamos GhostRace, el primer análisis de seguridad de estas primitivas en rutas de código ejecutadas de manera especulativa.

Nuestro hallazgo clave es que todas las primitivas de sincronización comunes implementadas utilizando ramificaciones condicionales (Figura 1) pueden ser eludidas microarquitectónicamente en rutas especulativas mediante un ataque Spectre-v1, convirtiendo todas las regiones críticas libre de carreras arquitectónicamente en Condiciones de Carrera Especulativas (SRC), permitiendo a los atacantes filtrar información del software objetivo.

Primitivas de Sincronización Especulativa Nuestro análisis muestra que todas las otras primitivas comunes de sincronización del lado de escritura en el kernel de Linux se implementan en última instancia a través de una rama condicional y, por lo tanto, son vulnerables a condiciones de carrera especulativas.

Para confirmar experimentalmente esta intuición, probamos todas estas primitivas de sincronización bajo ejecución especulativa después de malentrenar la rama vulnerable. En todos los casos, confirmamos la ejecución transitoria de la región crítica protegida a pesar de que otro hilo víctima ya está ejecutando arquitectónicamente en la región. Para determinar el tamaño de la ventana transitoria, medimos el número máximo de instrucciones de carga especulativas que podríamos ejecutar especulativamente dentro de la región crítica (Figura 2)

SCUAF Gadget Scanner

Para investigar la gravedad de las Condiciones de Carrera Especulativas (SRCs), nos centramos en el Uso Después de Liberar Especulativo Concurrente (SCUAF) y escaneamos estáticamente el kernel de Linux con Coccinelle (Figura 3), descubriendo 1,283 dispositivos potencialmente explotables

 

IPI Storming: CVE-2024-26602

Para ganar una SRC, necesitamos interrumpir la ejecución del proceso víctima en el momento adecuado (es decir, cuando se crea el puntero colgante) y mantener al proceso víctima allí para siempre para que el atacante pueda llevar a cabo el ataque SCUAF. Para lograr esto, creamos una nueva técnica de explotación llamada Tormenta de Interrupción entre Procesos (IPI, por sus siglas en inglés), que consiste en inundar infinitamente el núcleo de la CPU del proceso víctima con IPIs una vez interrumpido, de modo que nunca termine de manejar las interrupciones entrantes, lo que resulta en la creación de una ventana de explotación ilimitada que permite al atacante ejecutar un número arbitrario de invocaciones SCUAF para montar un ataque de extremo a extremo dentro de una única ventana de carrera. En la Figura 4 mostramos cómo el aumento del número de SMTs que generan tormentas amplía la ventana de explotación de UAF.

SCUAF Information Disclosure Attacks

Además, demostramos que los ataques de divulgación de información SCUAF (Figura 5) en el kernel son factibles y pueden igualar la fiabilidad de los ataques típicos de Spectre, con nuestro concepto de prueba filtrando memoria del kernel a 12 KB/s.

Código

Puedes encontrar un PoC minimalista que ejemplifica el concepto de SRC de manera paso a paso en un hilo de ejecución único, scripts de escaneo SCUAF de Coccinelle y más de 1200 gadgets SCUAF encontrados en el kernel de Linux en https://github.com/vusec/ghostrace

Hardware y Software Afectado

Aunque nos hemos enfocado explícitamente en x86 y Linux en el documento, las SRCs también afectan a otros objetivos de hardware y software.

Hardware: Hemos confirmado que todos los principales proveedores de hardware están afectados por las SRCs, ya que, independientemente de la implementación particular de la instrucción de comparación e intercambio, la rama condicional que sigue está sujeta a la (mis)predicción de la rama. En otras palabras, todas las microarquitecturas afectadas por Spectre-v1 también están afectadas por las SRCs.

Software: Cualquier objetivo que dependa de ramas condicionales para determinar si ingresar a regiones críticas, un patrón de diseño común que se extiende mucho más allá de Linux, es vulnerable a las SRCs.

En resumen, cualquier software, como sistemas operativos, hipervisores, etc., que implemente primitivas de sincronización a través de ramas condicionales sin ninguna instrucción de serialización en ese camino y que se ejecute en cualquier microarquitectura (por ejemplo, x86, ARM, RISC-V, etc.), que permita que las ramas condicionales se ejecuten especulativamente, es vulnerable a las SRCs. Como en otros ataques de ejecución especulativa, esto permite la filtración de datos del software objetivo.

Mitigación

Para abordar la nueva superficie de ataque, también proponemos una mitigación genérica de las SRC para serializar todas las primitivas de sincronización afectadas en Linux (es decir, agregar una instrucción lfence después del lock cmpxchq en la Figura 1). Nuestra mitigación requiere cambios mínimos en el kernel (es decir, 2 líneas de código) y solo incurre en un sobrecosto de rendimiento de aproximadamente el 5% en la media geométrica en LMBench.

Divulgación Divulgamos las Condiciones de Carrera Especulativas a los principales proveedores de hardware (Intel, AMD, ARM e IBM) y al kernel de Linux a fines de 2023.

Los proveedores de hardware también notificaron a otros fabricantes de software afectados (sistemas operativos/hipervisores), y todas las partes han reconocido el problema reportado (CVE-2024-2193). Específicamente, AMD respondió con una declaración de impacto explícita (es decir, «las mitigaciones existentes [para Spectre-v1] se aplican»), señalando los ataques que dependen de la especulación errónea de ramas condicionales, como Spectre-v1.

Los desarrolladores del kernel de Linux no tienen planes inmediatos de implementar nuestra propuesta de serialización de primitivas de sincronización debido a preocupaciones de rendimiento. Sin embargo, confirmaron el problema de tormenta de IPI (CVE-2024-26602) e implementaron una función de limitación de la tasa de IPI para abordar el problema de saturación de la CPU mediante la adición de un mutex de sincronización en el camino de sys_membarrier y evitando su ejecución concurrente en múltiples núcleos. Desafortunadamente, como muestran nuestros experimentos (Figura 4), obstaculizar las primitivas de tormenta de IPI (es decir, 0 núcleos de tormenta) no es suficiente para cerrar completamente la superficie de ataque

Agradecimientos

Nos gustaría agradecer a los revisores anónimos por sus comentarios, a Andrew Cooper por sus primeros comentarios sobre el artículo, a Julia Lawall por las aclaraciones sobre Coccinelle y a Alessandro Sorniotti por las primeras discusiones sobre el proyecto. Este trabajo fue parcialmente apoyado por Intel Corporation a través del proyecto «Allocamelus», por el Consejo de Investigación Neerlandés (NWO) a través del proyecto «INTERSECT» y por el programa Horizon Europe de la Unión Europea bajo el acuerdo de subvención No. 101120962 («Rescale»).

FUENTE COMPLETA