Vulnerabilidad GhostRace
Se dio a conocer hace poco, información sobre un nuevo ataque de ejecución especulativa, bautizado como GhostRace (catalogado bajo CVE-2024-2193), este es un nuevo método desarrollado por investigadores de la Vrije Universiteit Amsterdam e IBM para explotar el mecanismo de ejecución especulativa presente en procesadores modernos de Intel, AMD, ARM e IBM.
Los investigadores mencionan que, GhostRace se enfoca en manipular condiciones de carrera especulativas para acceder a áreas de memoria previamente liberadas, lo que puede llevar a la extracción de datos sensibles del kernel de Linux, especialmente en entornos de virtualización donde un atacante en un sistema invitado puede comprometer la seguridad del sistema anfitrión o de otros sistemas invitados.
El funcionamiento del ataque se basa en la ejecución especulativa de instrucciones condicionales con primitivas de sincronización de subprocesos, como mutex y spinlock.
Si el procesador predice incorrectamente ramas en el código que manejan estas operaciones, se pueden realizar accesos especulativos a la memoria que ya ha sido liberada. Aunque el procesador descarta estos accesos después de detectar la predicción errónea, los rastros de ejecución permanecen en la memoria caché y pueden ser recuperados mediante técnicas de análisis de canal lateral.
GhostRace requiere la presencia de ciertas secuencias de instrucciones en el kernel, conocidas como gadgets, que son utilizadas para la ejecución especulativa dependiendo de condiciones externas controladas por el atacante. Estos gadgets se forman a partir de secciones de código donde se verifica el estado en un bucle sin fin y se sale del bucle después de eliminar el bloqueo de acceso al recurso. Esto permite activar falsamente una transición y ejecutar instrucciones protegidas por un bloqueo, a pesar de que el recurso permanece bloqueado.
Durante el análisis de la vulnerabilidad, que se realizó en el código del kernel de Linux 5.15.83, se reveló la presencia de 1283 dispositivos que podrían conducir a un acceso especulativo a la memoria ya liberada. Este tipo de ataque representa un riesgo potencial para sistemas de virtualización, cualquier kernel del sistema operativo y programas que utilicen primitivas de sincronización de subprocesos verificadas mediante declaraciones condicionales y se ejecuten en plataformas que permitan la ejecución especulativa de operaciones de ramificación, como x86, ARM, RISC-V, entre otros.
Para probar la vulnerabilidad, los investigadores desarrollaron un prototipo de exploit que demuestra la efectividad del ataque al permitir la extracción de datos de la memoria del kernel de Linux con un rendimiento de 12 KB por segundo y un nivel de confiabilidad similar a los ataques de la clase Spectre.
Los desarrolladores del kernel de Linux y las empresas de fabricación de CPU fueron informados sobre este problema a finales de 2023. AMD ya ha publicado un informe sobre la vulnerabilidad y recomienda el uso de técnicas estándar para protegerse contra ataques similares a Spectre v1. Por otro lado, Intel y ARM aún no han respondido a esta notificación.
Aunque los desarrolladores del kernel de Linux no tienen planes inmediatos de implementar la serialización de primitivas de sincronización debido a la pérdida de rendimiento, ya han incorporado restricciones para protegerse contra la técnica de explotación IPI Storming (CVE-2024-26602). Esta técnica de ataque implica interrumpir un proceso en el momento adecuado para proporcionar una ventana de tiempo para el acceso especulativo a la memoria liberada.
Para mitigar este tipo de ataque, se propone utilizar la serialización de primitivas de sincronización mediante la inclusión de una instrucción LFENCE después de la instrucción cmpxchq que verifica el estado de bloqueo. Sin embargo, esta medida de protección conlleva una penalización de rendimiento de aproximadamente el 5 % en el punto de referencia LMBench, debido a que la instrucción LFENCE deshabilita la ejecución preventiva de instrucciones posteriores antes de confirmar todas las operaciones anteriores.
En el caso del hipervisor Xen, los desarrolladores han preparado cambios para implementar el mecanismo de bloqueo protegido LOCK_HARDEN, similar al método BRANCH_HARDEN utilizado anteriormente. Sin embargo, debido a posibles impactos negativos en el rendimiento y la falta de evidencia de ataques en Xen, el modo LOCK_HARDEN está deshabilitado de forma predeterminada.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.