Branch Target Reuse (BTR), una técnica de Spectre-v2, aprovecha predicciones indirectas obsoletas cuando se libera código generado mediante compilación justo a tiempo (JIT) y se reutiliza su memoria. VUSec describe dos exploits de prueba de concepto contra el kernel de Linux; el detallado para cBPF filtra 8 bytes por segundo en CPU Intel modernas. El grupo también informa de una mitigación x86 integrada en la rama principal del kernel para ciertos casos de reutilización de código cBPF/eBPF.
Qué es Branch Target Reuse (BTR)
BTR se basa en que una predicción antigua de salto indirecto puede sobrevivir a la liberación del código JIT al que apuntaba. El procesador usa predicciones para decidir qué instrucciones ejecutar mientras determina el destino real de un salto; esa ejecución provisional se llama ejecución especulativa.
La técnica depende de que un atacante pueda ejecutar código sin privilegios en un motor JIT y de que una predicción obsoleta sobreviva y vuelva a seleccionarse. Si ocurre, la CPU puede dirigir la ejecución especulativa al código nuevo que ocupa una región de memoria reutilizada.
Cómo intervienen las predicciones obsoletas y el código JIT
El procesador guarda predicciones de saltos indirectos en una estructura llamada Branch Target Buffer (BTB), o búfer de destinos de rama. En la secuencia descrita por VUSec, se entrena un salto para que apunte a un bloque de código JIT; después se libera ese bloque y se reutiliza parcialmente su dirección para código nuevo. Si la predicción antigua sigue presente y el procesador vuelve a usarla, puede ejecutar especulativamente instrucciones del bloque nuevo desde un desplazamiento no previsto.
Así, el problema no depende solo de que el código cambie: también importa que una predicción de salto previa siga disponible cuando la memoria se reutiliza.
Qué informa VUSec sobre el cBPF de Linux
VUSec describe dos exploits de prueba de concepto de extremo a extremo contra el kernel de Linux. En el exploit detallado, programas cBPF instalados como filtros seccomp permiten filtrar 8 bytes por segundo en CPU Intel modernas.
La demostración recuperó el hash de la contraseña de root desde el proceso su, después de que su root lo cargara en memoria. Es un resultado de la demostración de investigación, no una medición general para Linux ni para otros motores JIT.
Qué muestran los resultados de SpiderMonkey y GraalVM
Los resultados varían según el motor. Para SpiderMonkey, el motor JavaScript de Firefox, VUSec describe ataques viables y una prueba de concepto con una filtración estimada de decenas de bytes por segundo en CPU Intel. La explotación completa del navegador requiere más trabajo.
En GraalVM, las pruebas lograron reutilizar direcciones y acceder especulativamente más allá de una operación de enmascaramiento, pero la compilación y la recolección de basura borraban las entradas del BTB antes de que pudieran usarse. VUSec describe la aleatorización de las ubicaciones de la caché de código JIT como una defensa de GraalVM. También señala que Mozilla había considerado medidas basadas en IBPB y priorizaba completar y desplegar el aislamiento de sitios.
La mitigación de Linux descrita por VUSec
VUSec informa de que los desarrolladores del kernel integraron en la rama principal una mitigación x86 para la reutilización de regiones JIT de cBPF/eBPF. Cuando un programa cBPF reutiliza una región ejecutada previamente, la medida ejecuta una barrera de predicción de ramas indirectas (IBPB) en todos los núcleos y desincentiva esa reutilización. Según VUSec, se aplica tanto si está habilitado el seguimiento de ramas indirectas (IBT) como si no.
