Un equipo de investigadores de la Vrije Universiteit Amsterdam ha identificado varias nuevas vulnerabilidades de clase Spectre-v2, publicadas bajo el nombre clave Training Solo, que permiten eludir los mecanismos de aislamiento de memoria. En el contexto de los sistemas de virtualización, las vulnerabilidades permiten determinar el contenido de la memoria del entorno host desde los sistemas invitados y, en el contexto de los servidores, determinar el contenido de la memoria del kernel cuando se ejecuta un exploit en el espacio de usuario. En GitHub se publican ejemplos de exploits para llevar a cabo tales ataques. Los exploits presentados permiten extraer datos arbitrarios de la memoria del kernel a una velocidad de 17 KB/seg y de la memoria del hipervisor a 8.5 KB/seg.
Los ataques Spectre-v2 utilizan la sustitución de valores en el búfer de destino de la rama o en el búfer de historial de la rama para predecir la próxima operación de la rama que filtrará datos. Al manipular el historial de transiciones, se crean condiciones para la predicción incorrecta de una transición durante la ejecución especulativa de instrucciones. El objetivo del atacante es garantizar que al realizar una operación de ramificación especulativa, la dirección para el salto se tome del área de memoria deseada. Después de realizar un salto especulativo, la dirección de salto leída de la memoria permanece en la memoria caché del procesador (bajo la apariencia de una dirección, se leen de la memoria los datos requeridos por el atacante). Para extraer información de la caché, se puede utilizar uno de los métodos para determinar el contenido de la caché basado en el análisis de los cambios en el tiempo de acceso a los datos almacenados en caché y no almacenados en caché.
Los métodos de ataque de Training Solo están diseñados para eludir los mecanismos de aislamiento de dominio como IBPB, eIBRS y BHI_NO, utilizados para bloquear los ataques Spectre-v2. Por ejemplo, la instrucción IBPB (Indirect Branch Prediction Barriers) garantiza que el estado del bloque de predicción de bifurcación se restablezca en cada cambio de contexto (cuando el control se transfiere entre el espacio del usuario y el núcleo o entre el sistema invitado y el entorno del host). Restablecer el estado deshabilita la capacidad de usar código personalizado para influir en el comportamiento del bloque de predicción de rama indirecta.
La diferencia entre los métodos de Training Solo es que para influir en el bloque de predicción de rama, se propone no lanzar código controlado por el atacante, sino utilizar código ya existente en el lado del área de ejecución privilegiada (kernel o hipervisor), desde donde el atacante está intentando filtrarse. De lo contrario, los métodos recuerdan al clásico ataque Spectre-v2. Además, los investigadores identificaron dos problemas de hardware (CVE-2024-28956 y CVE-2025-24495) que permiten eludir por completo el aislamiento de la región de ejecución y las fugas de procesos de otros usuarios, otros sistemas invitados o el entorno del host.

Hay tres tipos de ataques de entrenamiento individual:
- Distorsión de la lógica de predicción de ramas al llamar a secuencias de comandos (gadgets) que ya existen en el núcleo y que afectan el contenido del búfer del historial de ramas. Como tales gadgets, se propone utilizar el mecanismo de restricción de acceso a las llamadas del sistema SECCOMP, que permite, a través de la sustitución de sus filtros BPF, lograr una falsa transición indirecta en modo especulativo (los filtros en SECCOMP se configuran utilizando el clásico cBPF, habilitado por defecto, a diferencia de eBPF). Cuando se probó en las CPU Intel Tiger Lake y Lion Cove, la tasa de fuga con este método fue de 1.7 KB/seg.
- Uso de colisiones de IP (puntero de instrucción) en el bloque de predicción de rama. Un atacante puede crear condiciones bajo las cuales la dirección para un salto especulativo se seleccionará solo en función de la dirección de salto que ya está en el búfer, sin tener en cuenta el historial de saltos. La idea es que una operación de rama indirecta puede afectar a otra si ocurre una colisión al almacenar los hashes de sus direcciones en el BTB (Branch Target Buffer).
- Utilizando la influencia de las ramas directas para predecir ramas indirectas. Este comportamiento es causado por dos vulnerabilidades de hardware: CVE-2024-28956 (ITS, selección de objetivo indirecto) y CVE-2025-24495 (un problema en las CPU Intel con núcleos Lion Cove). La tasa de pérdida de memoria utilizando este método fue de 17 KB/seg. En el exploit demostrado, tomó 60 segundos determinar el hash de la contraseña del usuario root almacenada en la memoria después de llamar al comando "passwd -s".

Un ataque que corrompe el búfer del historial de bifurcaciones afecta a todas las CPU Intel compatibles con el mecanismo eIBRS, incluidas las CPU Intel Coffee Lake y Lion Cove. Para mitigar la vulnerabilidad, Intel publicó una actualización de microcódigo que implementa una nueva instrucción IBHF (Indirect Branch History Fence), que se propone especificar después del código que afecta al búfer del historial de bifurcaciones. Para las CPU Intel más antiguas, se ha propuesto un método de software para borrar el historial de bifurcaciones. Se ha adoptado un cambio en el kernel de Linux que añade software y hardware. protección contra ataques, realizado mediante cBPF. AMD declaró que el método de ataque no es efectivo contra sus CPU. ARM indicó que el problema solo afecta a procesadores ARM más antiguos, vulnerables a ataques Spectre-v2 y que no son compatibles con las extensiones FEAT_CSV2_3 y FEAT_CLRBHB.
La vulnerabilidad de selección de objetivo indirecto (ITS, CVE-2024-28956) afecta a las CPU Intel Core de 9.ª a 11.ª generación (Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet Lake, Ice Lake, Tiger Lake y Rocket Lake) y a las CPU Intel Xeon de 2.ª y 3.ª generación. La vulnerabilidad CVE-2025-24495 afecta a las CPU basadas en las microarquitecturas Lunar Lake y Arrow Lake. Los problemas se solucionaron en la actualización de microcódigo de ayer. Se ha adoptado un cambio en el kernel de Linux que bloquea el problema moviendo los saltos indirectos a la parte superior de la línea de caché.
Fuente: opennet.ru

