Inyección de privilegios de rama: explotación de condiciones de carrera en el predictor de ramas
(comsec.ethz.ch)- Branch Privilege Injection es una vulnerabilidad que vuelve a eludir las defensas de hardware de la familia Spectre-BTI que se habían mantenido durante unos 6 años, mediante una condición de carrera en el predictor de ramas de CPUs Intel
- El núcleo del ataque es que las actualizaciones del predictor de ramas se procesan de forma asíncrona respecto al flujo de instrucciones, y en ciertas condiciones pueden reflejarse con un retraso de decenas o cientos de ciclos
- Si quedan actualizaciones retrasadas durante una transición de privilegios o la ejecución de IBPB, estas pueden asociarse después al dominio de seguridad equivocado, rompiendo las garantías de seguridad de eIBRS e IBPB
- Los investigadores demostraron un ataque de extremo a extremo en Intel Raptor Lake de 13.ª generación sobre Ubuntu 24.04, con todas las mitigaciones predeterminadas activadas, filtrando memoria arbitraria a 5.6KiB/s
- La actualización de microcódigo de Intel bloqueó la primitiva de detección de la vulnerabilidad en la evaluación sobre Alder Lake, con un overhead de hasta 2.7%
Condiciones para que Branch Privilege Injection sea posible
- Branch Privilege Injection es un ataque de inyección de destino de rama, es decir, un ataque que vuelve a hacer viable Spectre-BTI en entornos Intel
- Las mitigaciones de hardware de Intel habían bloqueado este tipo de ataque durante unos 6 años, pero esta investigación muestra que una condición de carrera en CPUs Intel puede socavar esas defensas
- El ataque se basa en dos observaciones
- El predictor de ramas de los procesadores Intel se actualiza de forma asíncrona respecto al flujo de instrucciones
- En ciertas condiciones, la actualización se retrasa decenas o incluso cientos de ciclos
- La actualización asíncrona en sí no es la vulnerabilidad, sino una característica
- No hay sincronización suficiente entre el predictor de ramas y el flujo de instrucciones durante operaciones críticas para la seguridad
- Durante transiciones de modo usuario a kernel, o de invitado a hipervisor, las actualizaciones pueden seguir en curso
- También pueden quedar actualizaciones en curso durante la ejecución de IBPB
- Si esas actualizaciones llegan después del cambio de privilegios, se asocian no al privilegio anterior sino al nuevo modo de privilegio
- El predictor de ramas de los procesadores Intel se actualiza de forma asíncrona respecto al flujo de instrucciones
- Este tipo de vulnerabilidad se denomina Branch Predictor Race Conditions
Mitigaciones que se rompen y alcance del impacto
- eIBRS es la mitigación de Intel contra Spectre-BTI introducida en todos los procesadores desde la 9.ª generación Coffee Lake Refresh
- Su objetivo es aislar las predicciones de ramas indirectas entre distintos dominios de seguridad
- Está diseñada para asociar cada predicción con el dominio donde se generó y usar después solo las predicciones del dominio actual
- Si las actualizaciones en curso durante una transición de privilegios se asocian al nuevo dominio de seguridad, esa relación puede manipularse
- IBPB es un mecanismo usado para aislar sandboxes o máquinas virtuales que no confían entre sí dentro del mismo dominio de seguridad de hardware
- Ofrece una función para invalidar todas las predicciones de ramas indirectas
- Las actualizaciones en curso no se vacían con IBPB, por lo que pueden almacenarse en el predictor incluso después de la invalidación
- El alcance del impacto varía según la generación y la arquitectura
- Todos los procesadores Intel desde la 9.ª generación Coffee Lake Refresh están afectados por Branch Privilege Injection
- Se observaron predicciones que eluden IBPB hasta la 7.ª generación Kaby Lake
- No se encontraron problemas en los sistemas AMD y ARM evaluados
- El ataque de prueba de concepto se creó para Linux, pero como el problema de fondo está en el hardware, los sistemas operativos que se ejecuten sobre hardware afectado también resultan afectados
Mitigaciones, costo de rendimiento y materiales publicados
- Se recomienda instalar las actualizaciones más recientes del sistema operativo y del BIOS
- Intel desarrolló actualizaciones de microcódigo para los procesadores afectados, y los investigadores las evaluaron en Alder Lake
- La mitigación por microcódigo bloqueó la primitiva de detección de la vulnerabilidad
- Mostró un overhead de hasta 2.7% en Alder Lake
- También se evaluaron mitigaciones alternativas por software
- En Coffee Lake Refresh, el overhead fue de 1.6%
- En Rocket Lake, el overhead fue de 8.3%
- Los detalles técnicos pueden consultarse en el paper
- El paper sobre Branch Privilege Injection será presentado en USENIX Security 2025, y también está prevista una presentación en Black Hat USA 2025
- El código fuente del ataque y de los experimentos está publicado en github
1 comentarios
Comentarios de Hacker News
Entrada del blog de los investigadores: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Paper: https://comsec.ethz.ch/wp-content/files/bprc_sec25.pdf
En un escenario de ataque, al final es solo cuestión de tiempo para que toda la información de la memoria de la CPU termine en manos equivocadas
Es un buen artículo. En resumen, la actualización del predictor de ramas puede posponerse hasta mucho después de que la instrucción de rama se retire (retire)
Tiene sentido, porque si no, retirar la instrucción de rama tardaría más. Parece que las instrucciones de serialización de dispatch tampoco detienen el pipeline por actualizaciones pendientes del estado del predictor, lo cual es natural porque ya se distinguía entre “confirmar el resultado de la instrucción de rama” y “confirmar el resultado de la predicción”
Las instrucciones de cambio de privilegios tampoco detienen el pipeline por actualizaciones pendientes, pero eso solo es válido si se puede garantizar que el nivel de privilegio al crear la predicción y al confirmarla sea coherente. De lo contrario, una predicción creada por código de un nivel de privilegio puede confirmarse en el estado usado por otro nivel de privilegio
Quizás sea un problema difícil porque dentro del pipeline el nivel de privilegio actual no es un valor único y claramente definido
Qué gusto ver a Kaveh Razavi. Antes enseñaba en la Vrije Universiteit de Ámsterdam, y la materia de Hardware Security trataba estos temas a fondo; era realmente genial
Me pregunto si hay grabaciones oficiales o apuntes en línea
¿Alguien sabe qué relación tiene esto con el ataque Training Solo que se acaba de publicar? https://www.vusec.net/projects/training-solo/
Training Solo entra al kernel, cambia el nivel de privilegio y luego, mediante “autoentrenamiento”, hace que una rama se prediga erróneamente hacia un disclosure gadget para filtrar memoria
Branch predictor race conditions entra al kernel mientras una actualización entrenada del predictor de ramas todavía se está procesando, haciendo que esa actualización quede asociada al nivel de privilegio equivocado. Luego usa eso de nuevo para redirigir una rama del kernel a un disclosure gadget y filtrar memoria
Si el predictor de ramas de la CPU pudiera usar de inmediato la información para verificar los límites de buffers y el nivel de privilegio del código, sería mucho más fácil evitar estos problemas
Pero parece que eso no va a pasar hasta que les arranquemos
void*de las frías manos a los programadores de C y reforcemos los punteros con información importantePara hacer lo que quieres, necesitarías una arquitectura de hardware en la que todas las cargas/almacenamientos pasen por algún tipo de “dirección aumentada” que almacene información de límites
Es decir, en la práctica estás pidiendo segmentación del 80286, que ya existió y no hizo lo que querías. La razón es que esos descriptores de segmento también tienen que ser cargados correctamente por el software. Desde el punto de vista del software, al final siguen siendo “solo punteros”, así que son vulnerables a los mismos errores
En el caso de la ejecución especulativa, para usar esa vulnerabilidad en algo real se necesita una preparación absurdamente grande. Prácticamente la única forma realmente utilizable es tener acceso directo a esa computadora y ejecutar código de bajo nivel. No es algo como filtrar secretos arbitrarios solo con código JS que corre en el navegador
Si un sistema es lo bastante valioso como para que una organización privada dedicada o una organización respaldada por un Estado haga la investigación y el trabajo de segmentación necesarios, entonces desde el principio debería tener un esquema que impida la ejecución de código arbitrario no autorizado
Personalmente, noto la mejora de rendimiento, así que tengo desactivadas todas las mitigaciones
Aviso de seguridad de Intel: https://www.intel.com/content/www/us/en/security-center/advi...
Me pregunto si el hardware de AMD tendrá una brecha similar. La ejecución especulativa parece una vulnerabilidad muy difícil de parchar en un espacio de procesador compartido, así que me intriga cómo AMD ha logrado evitarlo.
Dicen que no encontraron el problema en los sistemas AMD y ARM que evaluaron.
Fuente: https://comsec.ethz.ch/research/microarch/branch-privilege-i...
Esta vulnerabilidad en particular parece ser exclusiva de Intel, como Meltdown, pero AMD también era vulnerable al Spectre original.
Pero los motores de ejecución especulativa son complejos, así que los bugs y vulnerabilidades están muy extendidos.
Es muy probable que AMD y ARM también tengan bugs similares. Basta pensar en cuánto tiempo pasaron sin descubrirse estos bugs en Intel.
Por desgracia, la verdadera solución es reconocer que no se puede aislar el código que se ejecuta en sistemas modernos, lo cual podría ser fatal para los modelos de negocio de algunas empresas muy adineradas.
¿No es el mismo tipo de problema y solución que uno vería en software?
Dicen que “para cerrar este tipo de brecha se necesita una actualización especial del microcódigo del procesador. Puede hacerse mediante una actualización del BIOS o del sistema operativo, así que debería instalarse en la PC con una de las actualizaciones acumulativas más recientes de Windows”, pero ¿por qué mencionan solo Windows? ¿Y los usuarios de Linux?
Las distribuciones están configuradas para tomarlas de ahí y distribuirlas automáticamente.
Aunque no sé bien qué habría que revisar para confirmar si esta mitigación específica ya está incluida.
CONFIG_MICROCODE/CONFIG_MICROCODE_INTEL).Pero Intel tiene que publicar los archivos de microcódigo necesarios para que los mantenedores de las distribuciones puedan actualizar los paquetes, y luego se incluirán en las actualizaciones del sistema.
Me pregunto si Intel tiene alguna forma de recuperarse. No tiene productos convincentes en el mercado, la investigación y desarrollo toma mucho tiempo, y su fundición está rezagada frente a la competencia y sigue siendo una fuente de pérdidas.
Además, x86 está perdiendo cada vez más terreno frente al hardware ARM, y ahora RISC-V desde China también está creciendo. Claro que también está la perspectiva estadounidense sobre semiconductores. Sobre todo después de los problemas durante la pandemia, ¿dejaría EE. UU. caer a un fabricante clave como Intel?
La situación no es buena, pero el sensacionalismo es ridículo.
Los gamers son apenas un pequeño porcentaje de los usuarios de productos Intel, pero es de lo que más se escucha. Uno o dos pedidos de centros de datos son más grandes que todos los CPU para gaming que Intel vende en un año. Intel sigue aguantando bien en el mercado de centros de datos.
Además, Intel todavía domina el mercado de laptops empresariales, que también es bastante más grande que el mercado gamer.
Arm apenas tuvo 15% de cuota en el mercado de centros de datos el año pasado, y todavía no ha avanzado mucho en el mercado de Windows.
Independientemente de los productos, desde una perspectiva de accionistas/negocio, creo que el desempeño financiero hoy refleja cada vez menos los productos finales, así que intento pensarlo por separado; pero diría que Intel está cerca de ser demasiado grande para caer.
Quiero confirmar si entendí bien: ¿a estas alturas todos los sistemas operativos principales ya tienen parches para mitigar este problema o aplicar el microcódigo correspondiente?