Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace poco un investigador de seguridad de Google dio a conocer, mediante una publicación de blog, el descubrimiento de una nueva vulnerabilidad (CVE-2023-23583) en los procesadores Intel, con nombre en código Reptar, que afecta a varias CPU de escritorio, móviles y de servidor de Intel, pero especialmente a los sistemas en la nube que ejecutan máquinas virtuales de diferentes usuarios.

La vulnerabilidad «Reptar» permite que el sistema se cuelgue o bloquee cuando se realizan determinadas operaciones en sistemas invitados sin privilegios. 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.

El equipo de ingeniería de seguridad de la información de Google informó la vulnerabilidad a Intel, quien la reveló hoy. Gracias a la cuidadosa colaboración entre Google, Intel y los socios de la industria, se implementaron mitigaciones y los empleados de Google y nuestros clientes están protegidos.

Según el investigador, la vulnerabilidad está presente en una gran cantidad de familias de procesadores Intel y se informa que el problema aparece a partir de la décima generación de los procesadores Intel Core y la tercera generación de los procesadores Xeon Scalable, así como en los procesadores Xeon E/D/W.

Sobre Reptar

Se menciona que la vulnerabilidad se debe al hecho de que la ejecución de una instrucción «REP MOVSB» codificada con un prefijo «REX» (un prefijo de un solo byte) redundante da como resultado un comportamiento indefinido. El prefijo REX puede proporcionar bits adicionales a la siguiente instrucción para usarlos como operandos, por lo que permite codificar los 16 registros de propósito general posibles y estos bits opcionales dan espacio para codificar registros de propósito más general en la siguiente instrucción.

En agosto, nuestro proceso de validación produjo una afirmación interesante. Encontró un caso en el que agregar prefijos REX redundantes a una operación «rep movs» optimizada de FSRM parecía causar resultados impredecibles.

Observamos un comportamiento muy extraño durante las pruebas. Por ejemplo, bifurcaciones a ubicaciones inesperadas, bifurcaciones incondicionales que se ignoran y el procesador ya no registra con precisión el puntero de instrucción xsaveo calllas instrucciones.

Curiosamente, al intentar comprender lo que estaba sucediendo, veíamos un depurador que informaba estados imposibles.

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» provoca corrupción en el contenido del búfer ROB (ReOrder Buffer) utilizado para ordenar instrucciones.

Una característica interesante de x86 es que la decodificación de instrucciones es generalmente bastante relajada. Si utiliza un prefijo que no tiene sentido o entra en conflicto con otros prefijos, no sucederá gran cosa, normalmente simplemente se ignorará.

Este hecho es a veces útil; los compiladores pueden usar prefijos redundantes para rellenar una sola instrucción hasta un límite de alineación deseable.

Se cree que el error se debe a un cálculo incorrecto del tamaño de la instrucción «MOVSB» con un prefijo excesivo, lo que conduce a una violación del direccionamiento de las instrucciones escritas en el búfer ROB después de MOVSB ​​y al 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 bloquea varios núcleos o subprocesos SMT al mismo tiempo, puede causar suficiente daño al estado de la microarquitectura como para bloquearlo.

Una revisión interna de Intel también mostró el potencial de explotación de la vulnerabilidad para aumentar los privilegios bajo ciertas condiciones.

Finalmente, cabe mencionar que para probar la integridad de los sistemas, se ha publicado una utilidad que crea las condiciones para la manifestación de vulnerabilidades, además de que la vulnerabilidad en cuestión se solucionó en la actualización del microcódigo 20231114.

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.