Lord of the Ring(s): La nueva vulnerabilidad descubierta en los procesadores de Intel

Lord of the Ring(s): La nueva vulnerabilidad descubierta en los procesadores de Intel

Hoy nos topamos con la vulnerabilidad Lord of the Ring(s) (LOTR) en los procesadores de Intel, un guiño a la película de El Señor de los Anillos, y este guiño es debido a una vulnerabilidad ligada a los anillos de interconexión de los procesadores de la compañía azul, aunque en este caso concreto, no es crítica debido a las dificultades a las que se deberían enfrentar los atacantes para tener acceso a la información.

Los encargados de dar a conocer esta vulnerabilidad fueron el estudiante de doctorado Riccardo Paccagnella, el estudiante de máster Licheng Luo y el profesor adjunto Christopher Fletcher, todos ellos de la Universidad de Illinois en Urbana-Champaign. En su conjunto, investigaron el funcionamiento de las interconexiones en anillo de la CPU y descubrieron que se puede abusar de ellas para realizar ataques de canal lateral. El resultado es que una aplicación puede deducir la memoria privada de otra y husmear las pulsaciones realizadas en el teclado por parte del usuario.

"Es el primer ataque que aprovecha la contención en la interconexión entre los núcleos de las CPUs de Intel", dijo Riccardo al periódico The Register. "El ataque no se basa en la compartición de memoria, conjuntos de caché, recursos core-private o cualquier estructura uncore específica. Como consecuencia, es difícil de mitigar con las defensas de canal lateral existentes".

Con ese conocimiento, descubrieron que podían filtrar bits de claves criptográficas de las implementaciones RSA y EdDSA, que ya se sabe que son vulnerables a los ataques de canal lateral. También demostraron que podían vigilar las pulsaciones realizadas en el teclado, lo que, según investigaciones anteriores, puede utilizarse para reconstruir las contraseñas escritas, además de una vulneración de la privacidad.

Vulnerabilidad Lord of the Ring(s)

El reto al que se enfrentaron los investigadores fue doble: en primer lugar, Intel no ha proporcionado muchos detalles sobre el funcionamiento de su bus de anillo de la CPU. Por ello, fue necesario realizar una importante labor de ingeniería inversa.

En segundo lugar, su ataque se basa en la contención, que en este caso implica la supervisión de la latencia cuando diferentes procesos acceden a la memoria al mismo tiempo. Esta observación es difícil porque hay mucho ruido que hay que identificar y filtrar, y los eventos significativos, como las pérdidas de caché privadas (cuando un sistema busca datos en una caché que no está ahí), no son tan comunes.

Riccardo dijo que los dos ataques demostrados implican a un atacante local que ejecuta código sin privilegios en la máquina de la víctima, como un malware oculto en una biblioteca de software o una aplicación que espía a otros programas o usuarios. Dijo que un escenario basado en la nube, donde el adversario es un administrador o co-arrendatario de un sistema compartido, también puede ser posible, pero tanto él como sus socios prefirieron no hacer esa afirmación porque los ataques de demostración se ejecutaron en un entorno no virtualizado y no se han probado en otras circunstancias.

El ataque criptográfico asume que el Simultaneous Multi Threading (SMT) ha sido desactivado, que la caché de último nivel (LLC) ha sido particionada para defenderse de los ataques basados en la caché multinúcleo, y que la compartición de memoria entre dominios de seguridad ha sido desactivada. También asume que el sistema está configurado para borrar la huella de la caché del objetivo para evitar ataques de programación preventiva basados en la caché.

"Intel clasificó nuestro ataque como un 'canal lateral tradicional' (como TLBleed, Portsmash, etc.)", dijo Paccagnella. "Tratan esta clase de ataques de forma diferente a la clase de 'ataques de ejecución especulativa / ejecución transitoria' (como Spectre, Meltdown, etc.). Es decir, no consideran los ataques tradicionales de canal lateral como un valor significativo para un atacante y ya publicaron su guía sugerida sobre cómo mitigarlos."

"El código verdaderamente en tiempo constante puede ser difícil de implementar en la práctica. Además, se necesitará un soporte de hardware adicional para lograr el "aislamiento de dominio" en la interconexión en anillo".

Artículos relacionados