Análisis

Análisis: Meltdown

Analizamos en profundidad de uno de los dos graves fallos de seguridad

Llegó 2018. Y el 2 de enero en un artículo de The Register se hacía público el fallo de seguridad de componentes más grave en la historia de la tecnología. Este ha dado lugar a 3 agujeros de seguridad: 2 de ellos que explotan la vulnerabilidad conocida como Spectre (que analizaremos en un próximo artículo) y uno de ellos a la vulnerabilidad de la que hablamos en este artículo: Meltdown.

Vamos a intentar arrojar luz en un tema de por sí complejo, pues hablamos directamente de arquitectura de procesadores, pero vamos a acercarlo a casos reales para que lo entendamos mejor.

Ejecución fuera de orden

Esta es la clave de Meltdown. Una técnica que aunque viene usándose desde los años 60, fue en 1995 con la salida del Intel Pentium Pro cuando se popularizó y empezó a ser usada hasta hoy día.

Las operaciones que realiza un procesador son, en esencia muy sencillas. Son básicamente operaciones algebraicas o de movimiento de datos en memoria. Cargamos datos en los registros, los procesamos con una operación que puede ser aritmética o lógica y obtenemos un resultado. A esto sumamos el mover datos en memoria: desde o hacia los registros o entre propias direcciones de la memoria.

Pero un procesador tiene pausas que le permiten no dedicarse a una única tarea en un espacio de tiempo. Y en esas pausas van entrando diferentes tareas que son procesadas para darnos “la sensación” que hay una multitarea cuando no la hay. Hay muchas operaciones de diferente fuente procesadas rápidamente. Tan rápido que nos parece que hace varias cosas a la vez. Con el tiempo los procesadores sí ganaron la capacidad de tener varios hilos de proceso que funcionan a la vez, pero la esencia es la misma.

Pero esta forma de procesamiento tiene un problema: que deja huecos donde en un tiempo reservado para el cálculo de una operación, no se hace nada. Las operaciones depende de los ciclos de reloj de la CPU. De forma, que la ejecución fuera de orden intenta aprovechar los huecos de ciclos de reloj vacíos para llenarlos con operaciones que, aun no siendo el momento en que han de ser ejecutadas, ya se han solicitado y solo esperaban su momento. Así que se procesan antes o después, ordenando luego los resultados para que parezca que han sido procesadas en orden. Determinar el cuándo son procesadas, depende del momento en que los recursos necesarios para realizar las instrucciones están disponibles.

Esa es la base del fallo: la ejecución fuera de orden. Ahí, en la forma de estar implementada, es donde está uno de los errores que ha descubierto el equipo Project Zero de Google. Que lleva 23 años presente en todos nuestros equipos y que han podido ser explotados sin saberlo nosotros en forma alguna. Como podemos entender, el problema es serio.

Intel

Meltdown

Es un fallo que aprovecha una vulnerabilidad del sistema de ejecución fuera de orden, que permite acceder a toda la memoria del kernel del sistema.

Tal y como explican en el paper que explica el fallo, para cargar un dato de la memoria a los registros de la CPU, los datos en la memoria principal son referenciados mediante direcciones virtuales. Estas vienen marcadas de forma que se sepa si son accesibles por el usuario o solo por el kernel. Por seguridad, los sistemas operativos mapean todo el kernel bajo direcciones de memoria virtuales.

¿Qué hace Meltdown? Aprovecha la ejecución fuera de orden y que la CPU tiene acceso completo a la memoria del kernel para colarse entre un intento de acceso y el error que salta al comprobar la seguridad, que reconoce que un proceso de usuario no puede acceder a ese dato por ser del kernel. Es decir, se cuela entre la comprobación del error y la excepción que genera ese error, aprovechando esta ejecución fuera de orden.

¿Y dónde lee los datos? De los registros de la caché que se usan para precargar los datos necesarios para hacer una operación. Del lugar donde se guardan los recursos necesarios para hacer esa operación mientras le toca su turno para ser ejecutada.

El proceso del ataque es el siguiente: el atacante le pide a la CPU cargar un dato de un lugar de la memoria a la que él no puede acceder (del kernel). La CPU carga esta información y la almacena en la caché donde espera su turno dentro de la cola de la ejecución fuera de orden. Cuando llega el turno de la ejecución, antes de hacerla se comprueba si quien pidió esta tiene permiso para acceder al dato que se pidió. Obviamente, no lo tiene, así que se lanza la excepción que impide el acceso y se borra el dato guardado. Pero estos procesos también entran dentro de la ejecución fuera de orden, así que nos colamos con un proceso que se ejecuta antes del borrado y la excepción y leemos y extraemos la información de la caché antes de ser borrada. La forma de extraer esta información es a través de computación especulativa, la base del fallo Spectre y del que hablaremos en un próximo artículo. Por ahora nos quedamos solo con que podemos acceder a este dato.

Meltdown Prueba de Concepto

Es importante entender que el fallo de diseño está en que se comprueba si el proceso que ha pedido el dato tiene derecho de acceso al mismo cuando se realiza la operación, no cuando se solicita. Si la comprobación se hiciera cuando pedimos el dato (que sería lo más lógico) comprobando si podemos o no acceder al mismo, no existiría ese fallo. Pero no se hace así. Cuando pedimos un dato, este se carga siempre independientemente de si podemos o no acceder al mismo. Esto no supondría un error sino fuera porque podemos colarnos con otro proceso en esa caché (que está desprotegida y sin cifrar) y leer su contenido.

Si hacemos un mapeo de todas las direcciones de memoria virtuales que tiene registradas el kernel, repitiendo los pasos expuestos, podemos hacer un volcado completo de toda la memoria en un momento determinado para ver o extraer cualquier dato que haya en ella. Trozo a trozo, podemos extraer toda la información que tiene el propio kernel en esos momentos en la memoria.

KAISER

Parchear hardware es imposible. No podemos poner un parche a un fallo de diseño de un chip. La única forma de solucionarlo es haciendo un nuevo chip que no tenga este fallo de diseño. No obstante, sí podemos hacer algo a nivel de software que solucione este error. Para ello, ponemos una capa software a bajo nivel que se coloque delante del error. Nuestro software seguirá funcionando como hasta ahora, pero cuando llame a algo en vez de hacerlo al chip lo hará a una función que será quien se encargue de llamar al chip.

En este caso existe un parche que Apple tiene implementado desde la versión 10.13.2 de forma parcial, que crea un aislamiento de la tabla de página de memoria del Kernel. Esto, pone esa comprobación necesaria en el momento justo: verificar que alguien que pide un dato tiene derecho de acceso al mismo antes de cargarlo.

Este parche, que no fue creado específicamente para contrarrestar a Meltdown, se ha demostrado que es efectivo a la hora de mitigar la explotación de esta vulnerabilidad. Apple y Windows sacarán próximamente parches que implementen este cambio completo a alto nivel y Linux ya lo tiene disponible.

Es cierto que esto ralentizara las máquinas, pero su incidencia real (tras las primeras alarmas) será mínima porque no afecta a todas las operaciones por igual y no es algo lineal. En las primeras pruebas realizadas por grandes distribuidores como Amazon o Azure (en sus equipos para la nube) o la propia Apple en sus dispositivos, no se han detectado bajadas de rendimiento superiores al 5% y nunca constantes. No obstante, solo el uso nos dirá realmente hasta qué punto estarán o no afectados los dispositivos.

Sistemas afectados

Esta vulnerabilidad puede explotarse incluso desde un navegador usando código javascript motivo por el que los navegadores de internet están siendo actualizados para evitar esta ejecución de código. En el caso de Firefox, debemos tener al menos la versión 57.0.4.

Firefox 57.0.4

Meltdown solo ha conseguido explotarse por parte de Google en procesadores Intel, no en AMD o de arquitectura ARM. No obstante, se ha comprobado que las circunstancias que exponen los datos en la CPU sí que funcionan en estos procesadores, aunque el exploit que funciona en los Intel no ha permitido acceder a la información.

Investigaciones posteriores de ARM han informado que sí tienen algunas arquitecturas Cortex afectadas por este error. No todas, pero algunas. Incluso por una pequeña variante del mismo Meltdown que ha encontrado la propia ARM. Y en AMD aun no está claro qué arquitecturas o procesadores podrían realmente estar afectados. En el caso Intel, Meltdown no afecta a los procesadores Intel Itanium y Atom fabricados antes de 2013.

Meltdown, catalogado como el fallo CVE-2017-5754 es un fallo bastante crítico, el más peligroso de los tres encontrados (porque es más fácil de explotar como ya hemos comentado) y es el que más debe preocuparnos. Todos los fabricantes están trabajando en parchearlo, para lo cual hay que estar siempre al día de actualizaciones y en cuanto salga alguna para nuestro ordenador, dispositivo, NAS, servidor, etc… hemos de instalarlo.

Meltdown no es un virus, por lo que nuestro antivirus no puede detectarlo. Es un agujero de seguridad y solo un parche que cierre dicho agujero nos permitirá seguir trabajando sin problema. Mientras llegan las actualizaciones, la forma más sensata de mantenerse protegido es usar el sentido común, no entrar en páginas que no sean de confianza, actualizar todo a la última versión y esperar que este problema se cierre.

Si tenéis cualquier duda, no dejéis de escribirnos en los comentarios y contestaremos a todas vuestras dudas. Un saludo y good Apple Coding.

Enlaces de interés:
– Meltdown Whitepaper | Descargar
– Información de seguridad de ARM | Visitar

Etiquetas

Julio César Fernández

Analista, consultor y periodista tecnológico, desarrollador, empresario, productor audiovisual, actor de doblaje e ingeniero de vídeo y audio.

Artículos relacionados

Cerrar
Cerrar