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
Más información:
Fuente: Hispasec
