19 de agosto de 2018

FORESHADOW. Nuevo ataque basado en la ejecución especulativa

A Spectre y Meltdown se les suma un nuevo ataque (en realidad son varios) del tipo "ejecución especulativa". Las consecuencias, al igual que los anteriores ataques, es la capacidad de leer zonas de la memoria a las que no se debería de tener acceso.
Este tipo de ataques se basan, como ya hemos mencionado, en la ejecución especulativa. ¿Qué es? Es una técnica de optimización que utilizan los microprocesadores para ir "adelantando" trabajo. Mientras que un grupo de instrucciones se está ejecutando, otro hilo del procesador puede ejecutar instrucciones futuras o acceder a recursos adicionales basado simplemente en la especulación, es decir, en "creer" que el proceso va a necesitar esos cálculos o recursos en un futuro. Naturalmente, eso es una apuesta con sus correspondientes probabilidades, siendo normal y factible que todo ese trabajo que se ha adelantado no sirva para nada, dado que el proceso puede derivar perfectamente en otro cauce de ejecución.
Por poner un ejemplo más mundano, supón que un día ves con tus amigos dos capítulos de una serie, preparáis las bebidas, palomitas y os acopláis en el sofá. Al día siguiente hacéis lo mismo, al otro también y como supones que eso va a ocurrir al siguiente del siguiente (porque a la serie le quedan dos capítulos para que termine), preparas el refrigerio y acomodas el salón antes de que tus amigos aparezcan, pero llega el momento y tus amigos no llegan. ¿Qué haces? Te comes el refrigerio tu sólo porque no ha servido para lo que pensabas. Has adelantado trabajo "especulando" qué podría ocurrir.
Las víctimas de "Arquitectura de Computadores I, II y III", saben que diseñar microprocesadores de cierta complejidad es una tarea destinada a unos pocos seres humanos con cierto volumen craneal, necesario para evitar la expansión cerebral que produce el calentamiento inherente al diseño de estos ingenios. Y como con todo lo que conlleva la palabra humano: nada es perfecto. Así que cuando diseñaron la forma en la que se traducen direcciones de la memoria virtual de un proceso de usuario a memoria física (o real), incluyeron también la posibilidad de mapear la memoria del kernel y de paso, la de otros procesos. ¿Qué podría salir mal?
Ojo, que esto no significa que a las bravas puedas leerlo. No, no, no. De ningún modo. Un proceso de usuario no puede venirse arriba y decir: "Venga, voy a aprovechar que tengo pendiente una lectura de disco y me voy a guardar cuatro páginas enteras de memoria del kernel y de paso un par del proceso bash del vecino". Para ello existe un mecanismo que comprueba si dicho proceso posee derechos de acceso a esas partes de la memoria. Una especie de aduana digital donde se comprueba la mercancía que se está intentando llevar un proceso. "Oiga, pollo, pare, pare. ¿De donde ha sacado usted esos 256 bytes con pinta de clave RSA privada. ¿Ah, que es de un amigo? ¡Claro!, como no. Venga por aquí."
¿Cómo se explota?
Bien, hemos comentado a muy alto nivel que todo esto se basa en adelantar trabajo, ya sea ejecutando de antemano saltos en el código que podrían o no ejecutarse (predicción de saltos), procesar conjuntos de instrucciones que se pueden ejecutar de forma independiente al conjunto en ejecución actual (ejecución fuera de orden), etc. Y por otro lado, hemos dicho que en la memoria de un proceso, por diseño, se mapean las direcciones de la memoria del kernel y otros procesos (debido a que se está traduciendo memoria virtual a física y viceversa).
Pues el problema principal de seguridad es que cuando se está produciendo la ejecución especulativa, no se están revisando los privilegios de un proceso respecto a esa zona de memoria. Se dejan para después, cuando se hace efectiva la ejecución adelantada. Mientras tanto, los datos de esas zonas de memoria a las que no se debería acceder, permanecen en la memoria caché, donde mediante la aplicación de ciertas técnicas, pueden ser leídas. Esto es en lo que, de forma general, se basan este tipo de vulnerabilidad.
Foreshadow y Foreshadow-NG
Foreshadow fue descubierta por un grupo de investigadores procedentes de varias universidades y centros de investigación. Pertenece a la familia de fallos sobre los que ya hemos hablado, ataques sobre la ejecución especulativa. En particular, este ataque se centra sobre una característica en particular SGX (Software Guard Extensions). Esta tecnología permite a un proceso de usuario proteger una zona de memoria incluso del acceso por parte de procesos más privilegiados.
Por poner un ejemplo, supongamos que mapeamos 16 kilobytes de memoria y la protegemos mediante SGX, pues se supone que ni siquiera un proceso root podría tener acceso a ese fragmento de datos. Esto permite un nivel de protección muy útil cuando queremos proteger datos de importancia sin recurrir a cifrado.
El grupo que descubrió el fallo reportó los detalles a Intel para que contrastaran los hallazgos. Pues además de confirmar el fallo, el propio equipo de Intel ha descubierto una nueva forma de ataque que han denominado "L1 Terminal Fault" y que posibilitaría la lectura completa de la caché L1.
La caché L1 es la más cercana al procesador (existe una jerarquía de memorias caché, clasificadas según la "cercanía" al procesador), lo que significa que posee poca capacidad relativa de memoria pero una alta velocidad en la recuperación de datos e instrucciones. Esto se traduce en una memoria muy viva, con datos de procesos que están siendo ejecutados en ese momento y por supuesto, muy relacionada con la ejecución especulativa de estos últimos. Razón por la cual, con los elementos que ya hemos explicado, la hace objeto de la tormenta perfecta.
Consecuencias. Es posible leer la caché L1, pieza útil en mecanismos como el ya descrito SGX, memoria del kernel y máquinas virtuales, además de memoria del modo SMM (System Management Mode) que regula funciones de muy bajo nivel relacionadas con el hardware subyacente, por ejemplo, la gestión de energía, etc. Como apuntan en el estudio, esto tiene importantes consecuencias en la nube, donde el uso de la virtualización forma la espina dorsal del paradigma.
Intel ha actualizado el microcódigo de los procesadores afectados, aunque señala que habrá que actualizar sistemas operativos y las soluciones de virtualización para impedir la explotación del fallo. Tanto Microsoft como el kernel Linux han aportado ya una solución para la causa en la parte que les toca.
Se han asignado los siguientes CVEs para las distintas variedades del ataque:
- CVE-2018-3615 para el ataque sobre SGX
- CVE-2018-3620 para la memoria del kernel y SMM
- CVE-2018-3646 para el que afecta a máquinas virtuales
Podéis encontrar una amplia lista de procesadores afectados en la página  https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html
Más información:
Fuente: Hispasec