Vulnerabilidad Reptar que afecta a los procesadores Intel

Tavis Ormandy, investigador de seguridad de Google, ha identificado una nueva vulnerabilidad (CVE-2023-23583) en los procesadores Intel, cuyo nombre en código es Reptar, que supone una amenaza principalmente para los sistemas en la nube que ejecutan máquinas virtuales de diferentes usuarios. La vulnerabilidad permite que el sistema se cuelgue o bloquee cuando se realizan determinadas operaciones en sistemas invitados sin privilegios. Para probar sus sistemas, se ha publicado una utilidad que crea las condiciones para la manifestación de vulnerabilidades.

Teóricamente, la vulnerabilidad se puede utilizar para escalar privilegios del tercer anillo de protección al cero (CPL0) y escapar de entornos aislados, pero este escenario aún no se ha confirmado en la práctica debido a las dificultades de depuración a nivel de microarquitectura. Una revisión interna de Intel también mostró el potencial de explotación de la vulnerabilidad para aumentar los privilegios bajo ciertas condiciones.

Según el investigador, la vulnerabilidad está presente en las familias de procesadores Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake y Sapphire Rapids. El informe de Intel menciona que el problema aparece a partir de la décima generación (Ice Lake) de los procesadores Intel Core y la tercera generación de los procesadores Xeon Scalable, así como en los procesadores Xeon E/D/W (Ice Lake, Skylake, Haswell, Broadwell , Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket Lake) y Atom (Apollo Lake, Jasper Lake, Arizona Beach, Alder Lake, Parker Ridge, Snow Ridge, Elkhart Lake y Denverton). La vulnerabilidad en cuestión se solucionó en la actualización de microcódigo 10 de ayer.

La vulnerabilidad se debe al hecho de que, bajo ciertas circunstancias de microarquitectura, la ejecución de la instrucción "REP MOVSB" está codificada con un prefijo "REX" excesivo, lo que conduce a un comportamiento indefinido. El problema se descubrió durante las pruebas de prefijos redundantes, que en teoría deberían ignorarse, pero que en la práctica provocaban efectos extraños, como ignorar ramas incondicionales y romper el guardado de punteros en las instrucciones xsave y call. Un análisis más detallado mostró que agregar un prefijo redundante a la instrucción "REP MOVSB" causa corrupción en el contenido del búfer ROB (ReOrder Buffer) utilizado para ordenar instrucciones.

Se cree que el error es causado por un cálculo incorrecto del tamaño de la instrucción "MOVSB", lo que conduce a una violación del direccionamiento de las instrucciones escritas en el búfer ROB después de MOVSB ​​​​con un prefijo excesivo y el desplazamiento del puntero de instrucción. Esta desincronización puede limitarse a la interrupción de los cálculos intermedios con la posterior restauración del estado integral. Pero si fallas varios núcleos o subprocesos SMT al mismo tiempo, puedes dañar el estado de la microarquitectura lo suficiente como para fallar.

Fuente: opennet.ru

Añadir un comentario