Spectre v2: la variante BTR filtra datos en Intel, AMD y Arm
Una nueva variante de Spectre v2, recién revelada, permite extraer datos sensibles de la memoria en sistemas con procesadores Intel, AMD y Arm. Según los investigadores, el ataque funciona incluso contra equipos con todos los parches aplicados y la configuración de seguridad por defecto.
La técnica, bautizada como Branch Target Reuse (BTR), es obra del grupo VUSec de la Vrije Universiteit Amsterdam, en los Países Bajos, y de investigadores de la Scuola Superiore Sant'Anna, en Italia. Su objetivo son los compiladores just-in-time (JIT), que los núcleos de los sistemas operativos, los navegadores web y los entornos de ejecución utilizan para generar código sobre la marcha.
Un atacante que ya pueda ejecutar código en la máquina objetivo podría usar BTR para leer contenidos de la memoria, como hashes de contraseñas. Los investigadores creen que también son posibles ataques desde páginas web maliciosas, aunque todavía no han desarrollado un exploit completo para navegador.
Predicciones obsoletas que sobreviven al código
BTR se aprovecha de la forma en que los procesadores gestionan el código que se modifica mientras se ejecuta. Las CPU modernas se aseguran de que las instrucciones reales en memoria sigan siendo coherentes cuando el código se modifica a sí mismo. Con el predictor de saltos, la cosa cambia.
"La idea clave del ataque es que, aunque las CPU modernas restablecen la coherencia arquitectónica del código tras la automodificación, no invalidan necesariamente las entradas obsoletas de predicción de saltos indirectos (es decir, los destinos de salto)", explican los investigadores.
En un motor JIT, estas entradas desfasadas pueden seguir ahí después de que el código al que pertenecían haya desaparecido. Cuando se escribe código nuevo en esa misma zona de memoria, las predicciones antiguas pueden reutilizarse. Los investigadores lo llaman una primitiva especulativa de ejecución tras liberación (execute-after-free). Permite a un atacante dirigir la ejecución especulativa hacia el código nuevo en desplazamientos que ya no tienen sentido.
El equipo estudió tres objetivos: cBPF de Linux, el entorno de ejecución GraalVM de Oracle y SpiderMonkey, el motor de JavaScript y WebAssembly que utiliza Firefox.
Filtrado el hash de la contraseña de root desde el núcleo de Linux
Se construyeron dos exploits completos contra el núcleo de Linux, ambos basados en el BPF clásico (cBPF). Su sucesor, eBPF, está restringido a usuarios con privilegios, pero los programas sin privilegios pueden seguir usando cBPF. Seccomp, el filtrado de sockets y el filtrado de paquetes en programas como Docker y Chrome siguen dependiendo de él.
En las CPU modernas de Intel, el exploit lee memoria arbitraria y sortea todas las mitigaciones activadas.
"Nuestro exploit filtra 8 bytes por segundo. Puede parecer lento, pero con un seguimiento cuidadoso de punteros solo necesitamos filtrar una pequeña cantidad de datos para llegar al secreto", señalan los investigadores. En una demostración, localizaron y filtraron el hash de la contraseña de root una vez cargado en memoria.
Firefox y GraalVM, también afectados
En Firefox, el ataque partiría de una web maliciosa que ejecuta JavaScript en el navegador de la víctima. Mozilla no ha terminado de desplegar el aislamiento de sitios, así que el contenido de otras pestañas podría compartir espacio de direcciones con el código del atacante.
Una prueba de concepto demostró que, en chips de Intel, las entradas de salto obsoletas sobreviven en SpiderMonkey el tiempo suficiente para reutilizarse. Los investigadores calculan una velocidad de filtración de decenas de bytes por segundo, aunque un exploit funcional para navegador todavía requiere más trabajo.
En el caso de GraalVM, BTR podría permitir a un atacante saltar especulativamente el enmascaramiento de memoria que protege frente a Spectre el modo de aislamiento más estricto del entorno. Los investigadores lograron reutilizar direcciones de memoria de forma fiable, pero la compilación y la recolección de basura de GraalVM borraron las entradas obsoletas antes de que pudieran explotarse. Según ellos, este obstáculo "no parece fundamental".
Los fabricantes de chips señalan al software
Los fabricantes de chips y desarrolladores de software afectados fueron notificados y reconocieron los hallazgos. Los fabricantes de CPU afirmaron que las herramientas existentes, como la barrera de predicción de saltos indirectos (IBPB), pueden mitigar BTR, y que las correcciones corresponden al software.
Los desarrolladores del núcleo de Linux han añadido una mitigación para x86 que dispara una IBPB en cada núcleo de la CPU cuando un programa cBPF se coloca en memoria usada anteriormente por código BPF ejecutado. Oracle ha publicado algunas mitigaciones. Mozilla prioriza terminar el aislamiento de sitios frente a las correcciones basadas en IBPB.
Los investigadores confirmaron el comportamiento en todas las CPU de Intel, AMD y Arm que probaron. "Ninguna CPU actual tiene un mecanismo para mantener ambos sincronizados, así que, hasta que los fabricantes lo añadan, tu CPU es vulnerable", advierten.
Las protecciones de flujo de control por hardware, IBT en x86 y BTI en Arm, dificultan la explotación pero no eliminan el riesgo. Las CPU de Intel más antiguas todavía pueden ejecutar instrucciones de forma especulativa antes de que se produzca la comprobación. Lion Cove es la primera generación de Intel en la que los investigadores no encontraron esta condición de carrera. Aun así, consiguieron sortear IBT con el cegado de constantes desactivado, aunque consideran que la combinación de IBT sin condición de carrera y cegado de constantes es una defensa mucho más sólida.
AMD declaró a SecurityWeek que el artículo no revelaba ninguna vulnerabilidad nueva en sus productos y que las recomendaciones existentes para Spectre v2 mitigan la técnica. Intel y Arm no respondieron.
Nuestra opinión
BTR encaja en un patrón conocido: años después de que Spectre saliera a la luz, los investigadores siguen encontrando nuevas formas de esquivar las mitigaciones que debían cerrarlo. El problema de fondo está en el hardware, pero la carga de solucionarlo recae en los desarrolladores de núcleos, navegadores y entornos de ejecución. Eso apunta a una respuesta desigual, ya que cada proyecto valora de forma distinta el coste en rendimiento, como demuestra la decisión de Mozilla de centrarse en el aislamiento de sitios.
Para la mayoría de los lectores, lo práctico es mantener actualizados los núcleos de Linux, los navegadores y entornos como GraalVM a medida que lleguen estas mitigaciones. Los servidores multiusuario en los que usuarios no fiables pueden cargar filtros cBPF merecen especial atención. BTR se suma además a otras investigaciones, como un trabajo reciente que demostraba que las API de notificación de archivos filtran la actividad del usuario, para recordarnos que el comportamiento de bajo nivel del sistema puede exponer datos de formas inesperadas. Habrá que estar atentos a si aparece un exploit completo para navegador y a si los fabricantes de CPU acaban añadiendo un mecanismo de hardware que mantenga los predictores de saltos sincronizados con la memoria.