El equipo de VUSec revela tres variantes de ataques que comprometen la seguridad del kernel de Linux, rompen el aislamiento entre dominios y exigen actualizaciones urgentes de microcódigo y parches del sistema operativo
Una nueva serie de vulnerabilidades bautizadas como «Training Solo» ha sido revelada por el grupo de investigación en seguridad VUSec, afectando de forma significativa a procesadores Intel y núcleos Arm. La gravedad del hallazgo reside en que compromete mecanismos de aislamiento implementados para mitigar ataques del tipo Spectre v2, considerados hasta ahora eficaces en múltiples arquitecturas.
El estudio, publicado tras el levantamiento del embargo, detalla tres variantes distintas de Training Solo, todas ellas capaces de romper el aislamiento entre usuario, kernel, máquinas virtuales e incluso el hipervisor, a través de ataques basados en predicción especulativa y control de flujo.
¿En qué consiste «Training Solo»?
El ataque se basa en formas de autoentrenamiento del predictor de saltos del procesador, lo que permite al atacante manipular la predicción de saltos indirectos incluso dentro del mismo dominio víctima. A diferencia de Spectre clásico, donde el atacante y la víctima operan en contextos separados, Training Solo puede ser autoinducido dentro del kernel o extenderse a escenarios inter-dominio, facilitando la exfiltración de memoria sensible sin ejecutar código directamente malicioso.
El equipo de VUSec logró construir dos exploits funcionales que extraen memoria del kernel a velocidades de hasta 17 KB/s en procesadores Intel recientes.
Dispositivos afectados y mitigaciones
Las variantes de Training Solo afectan a una amplia gama de procesadores Intel, incluyendo:
- Cascade Lake
- Cooper Lake
- Whiskey Lake V, Coffee Lake R, Comet Lake
- Ice Lake, Tiger Lake y Rocket Lake
La mitigación de uno de los vectores, identificado como ITS (Indirect Target Selection), ya ha sido fusionada en el kernel Linux, e incluye actualizaciones de microcódigo por parte de Intel. Además, se requiere aplicar medidas adicionales en el hipervisor KVM y en subsistemas como eBPF, donde se ha integrado protección contra Branch History Injection (BHI) mediante instrucciones específicas como IBHF y BHI_DIS_S.
Implicaciones para la seguridad y el rendimiento
El desarrollador de Intel Dave Hansen describió ITS como “un clásico error de CPU donde el comportamiento es claramente incorrecto, pero pasó desapercibido porque solo generaba predicciones erróneas”. Sin embargo, su impacto es profundo, ya que socava múltiples mitigaciones implementadas tras Spectre, lo que obliga a rediseñar parte de la lógica defensiva del kernel.
Estos parches han comenzado a integrarse en los repositorios de Linux, y se espera que generen cierta penalización de rendimiento, especialmente en cargas que dependen de ejecución especulativa y contexto virtualizado. Las primeras pruebas de benchmark en entornos reales están en preparación por parte de la comunidad y serán clave para valorar el coste de las mitigaciones.
Un nuevo capítulo en la era post-Spectre
Desde 2018, cuando se revelaron las primeras vulnerabilidades Meltdown y Spectre, el ecosistema de hardware y software ha vivido un ajuste permanente en sus modelos de seguridad. Sin embargo, «Training Solo» demuestra que los atacantes siguen encontrando formas de abusar de la lógica predictiva de los procesadores, a pesar de años de mitigaciones y rediseños.
Los investigadores de VUSec advierten que incluso en configuraciones con aislamiento perfecto, estas nuevas formas de ataque pueden evadir las barreras actuales, lo que obliga a adoptar una postura de seguridad más proactiva y a nivel profundo de hardware.
Recomendaciones inmediatas
- Administradores de sistemas deben aplicar lo antes posible las actualizaciones de microcódigo de Intel, y actualizar a versiones del kernel que contengan las mitigaciones ITS y BHI.
- Entornos virtualizados y cloud deberán reforzar sus políticas de seguridad entre huéspedes, especialmente si se ejecutan cargas heterogéneas.
- Los desarrolladores de software deben revisar el uso de eBPF, especialmente en sistemas con soporte para programas cBPF que puedan ser vector de ataque.
Conclusión:
“Training Solo” vuelve a demostrar que las arquitecturas modernas siguen siendo vulnerables a ataques de canal lateral especulativo, y que el ciclo de “descubrimiento – mitigación – evasión” está lejos de concluir. La colaboración entre fabricantes, desarrolladores del kernel y comunidad de seguridad sigue siendo esencial para cerrar estas brechas, aunque a costa —una vez más— del rendimiento.
fuente: phoronix.com, Revista cloud y git kernel
