Un grupo de investigadores de la Universidad Libre de Ámsterdam ha descubierto varias nuevas vulnerabilidades de la clase Spectre-v2, publicadas bajo el nombre en código Training Solo, que permiten eludir los mecanismos de aislamiento de la memoria. En el contexto de los sistemas de virtualización, estas vulnerabilidades permiten determinar el contenido de la memoria del entorno host desde los sistemas invitados, y en el contexto de servidores, determinan el contenido de la memoria del núcleo durante la ejecución de un exploit en el espacio de usuario. Ejemplos de exploits para llevar a cabo tales ataques han sido publicados en GitHub. Los exploits presentados permiten extraer datos arbitrarios de la memoria del núcleo a una velocidad de 17 KB/s, y de la memoria del hipervisor a 8.5 KB/s.
En los ataques de la clase Spectre-v2, para organizar la fuga de datos se utiliza la inserción de valores en el búfer de direcciones de ramificación (Branch Target Buffer) o el búfer de historial de ramificaciones (Branch History Buffer), que se utilizan para predecir la siguiente operación de ramificación. A través de manipulaciones con el historial de ramificaciones se crean condiciones para una predicción incorrecta de la ramificación durante la ejecución especulativa de instrucciones. La tarea del atacante es que, al realizar una operación especulativa de ramificación, la dirección de la ramificación provenga de la zona de memoria deseada. Después de ejecutar la ramificación especulativa, en la caché del procesador queda la dirección de la ramificación leída de la memoria (los datos necesarios para el atacante se leen como si fueran una dirección). Para extraer información de la caché se puede aplicar uno de los métodos de determinación del contenido de la caché basado en el análisis del cambio en el tiempo de acceso a los datos almacenados y no almacenados en caché.
Los métodos de ataque Training Solo están diseñados para eludir los mecanismos de aislamiento de áreas de ejecución (domain isolation), tales como IBPB, eIBRS y BHI_NO, que se utilizan para bloquear los ataques de la clase Spectre-v2. Por ejemplo, la instrucción IBPB (Indirect Branch Prediction Barriers) garantiza un reinicio del estado del bloque de predicción de ramificaciones en cada cambio de contexto, que ocurre al transferir el control entre el espacio de usuario y el núcleo o entre el sistema invitado y el entorno host. El reinicio del estado bloquea la posibilidad de usar código propio para influir en el comportamiento del bloque de predicción de ramificaciones indirectas.
Las diferencias de los métodos Training Solo radican en que, para influir en el bloque de predicción de saltos, se propone no ejecutar código controlado por el atacante, sino utilizar código ya presente en la zona privilegiada de ejecución (núcleo o hipervisor), del cual el atacante obtiene filtraciones. En otros aspectos, los métodos son similares a un ataque clásico Spectre-v2. Además, los investigadores han identificado dos problemas de hardware (CVE-2024-28956 y CVE-2025-24495) que permiten eludir completamente la aislamiento de las áreas de ejecución y lograr filtraciones de procesos de otros usuarios, otros sistemas invitados o del entorno de host.
Se proponen tres tipos de ataques Training Solo:
- Distorsión de la lógica de predicción de saltos mediante la invocación de secuencias de comandos (gadgets) ya existentes en el núcleo, que afectan el contenido del búfer con el historial de saltos. Como tales gadgets se propone utilizar el mecanismo de restricción de acceso a llamadas del sistema SECCOMP, que permite lograr un falso salto indirecto en modo especulativo mediante la sustitución de sus filtros BPF (los filtros en SECCOMP se establecen utilizando el clásico cBPF, activado por defecto en lugar del eBPF). Durante las pruebas en CPU Intel Tiger Lake y Lion Cove, la velocidad de filtración utilizando este método fue de 1.7KB/sec.
- Uso de colisiones de dirección de instrucción (Instruction Pointer) en el bloque de predicción de saltos. El atacante puede crear condiciones en las que la dirección de un salto especulativo se elija únicamente en función de la dirección ya presente en el búfer, sin tener en cuenta el historial de saltos. La idea es que una operación de salto indirecto puede influir en otra si se produce una colisión al almacenar los hash de sus direcciones en el BTB (Branch Target Buffer).
- Uso de la influencia de saltos directos en la predicción de saltos indirectos. Este comportamiento es causado por dos vulnerabilidades de hardware: CVE-2024-28956 — ITS (Indirect Target Selection) y CVE-2025-24495 — un problema en CPUs Intel con núcleos Lion Cove. La velocidad de filtración de datos de la memoria utilizando este método fue de 17 KB/sec. En el exploit demostrado para determinar el hash de la contraseña del usuario root, guardada en memoria tras ejecutar el comando «passwd -s», se emplearon 60 segundos.
Todos los CPU Intel que soportan el mecanismo eIBRS, incluidos los CPU Intel Coffee Lake y Lion Cove, son vulnerables a un ataque que distorsiona el búfer con el historial de saltos. Para bloquear esta vulnerabilidad, Intel lanzó una actualización de microcódigo que implementa una nueva instrucción IBHF (Indirect Branch History Fence), la cual se recomienda indicar después del código que afecta al búfer de historial de saltos. Para los CPU Intel más antiguos, se sugiere utilizar un método de limpieza del historial de saltos basado en software. Se ha realizado una modificación en el núcleo de Linux que agrega métodos de software y hardware la protección contra ataques, realizados utilizando cBPF. AMD ha declarado que este método de ataque no afecta a sus CPU. ARM ha informado que el problema solo afecta a los procesadores ARM más antiguos, vulnerables a los ataques Spectre-v2 y que no soportan las extensiones FEAT_CSV2_3 y FEAT_CLRBHB.
La vulnerabilidad Indirect Target Selection (ITS, CVE-2024-28956) afecta a los CPU Intel Core de 9 a 11 generaciones (Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet Lake, Ice Lake, Tiger Lake y Rocket Lake) y a los Intel Xeon de 2 a 3 generaciones. La vulnerabilidad CVE-2025-24495 se manifiesta en CPU basados en las microarquitecturas Lunar Lake y Arrow Lake. Los problemas se solucionaron en la actualización de microcódigo de ayer. Se ha implementado un cambio en el núcleo de Linux que bloquea el problema trasladando los saltos indirectos a la parte superior de la línea de caché.
Fuente: opennet.ru
