Recientemente han aparecido dos vulnerabilidades de seguridad, estas afectan al hardware, no al software, y son muy graves, pues incluso su solución dejará secuelas. Meltdown afecta a todas las CPU de Intel y a algunos modelos de ARM, mientras que Spectre afecta a todos, también a los chips de AMD. Por lo tanto, prácticamente cualquier dispositivo equipado con un microprocesador moderno resulta afectado, desde móviles hasta servidores.

Ya le han hecho logotipo.

Las CPU modernas – o no tanto, pues ya hace unos años de esto – usan técnicas que aprovechan el paralelismo para acelerar la velocidad de procesamiento, una de ellas es la ejecución especulativa. El siguiente pseudocódigo permitirá un sencillo ejemplo de su funcionamiento:

si func1() = func2() entonces
   imprime func3()
fin si

En una arquitectura clásica, primero se ejecutaría la función 1, luego la 2 (o viceversa, depende del lenguaje) para, finalmente, si ambas dan el mismo resultado (este es el «peor» de los casos), ejecutarse la tercera. Su tiempo total equivaldría al de las tres funciones; pero gracias a la ejecución especulativa, la función 3 se calcula mientras se calculan la 1 y la 2, que también pueden paralelizarse, con lo que el tiempo total se reduce al de la función más lenta. Nótese que, si por ejemplo existiera alguna variable global que la función 3 consulta y que puede ser modificada por la 1 o la 2, esta paralelización no podría hacerse, con esta dificultad podemos imaginarnos lo compleja que resulta esta tecnología.

Esta es posible gracias a la duplicidad de las puertas lógicas en las CPU modernas y a la zona de memoria caché que, siguiendo el ejemplo, permite almacenar el resultado de la función 3 en espera de las dos anteriores. En lo que se refiere a la gestión de la memoria RAM, por razones de seguridad, tanto a nivel del microprocesador como a nivel del sistema operativo, existen medidas para evitar que un proceso pueda leer posiciones de memoria pertenecientes a otro. Gracias a ellas, cada proceso puede acceder sólo a la memoria que le ha asignado el kernel; en caso de necesitar más, le concederá más páginas, mientras que por otro lado libera las que dejen de usar otros procesos.

Pues bien, la vulnerabilidad está en el control de acceso a la memoria caché: la información ahí alojada temporalmente por la ejecución especulativa de un proceso, sería accesible por otro, mediante un hipotético exploit. Es decir, procesos que se ejecutan en ring-3 podrían acceder a información sólo disponible en ring-0, algo que debe ser posible sólo para el kernel del sistema operativo.

Spectre también. ¡Que cuco!

Hasta donde yo sé¹, todavía no ha sido publicado ningún exploit que aproveche completamente las posibilidades que otorga este fallo, pero al ser estas enormes, se está trabajando (me imagino que a destajo) desde hace días en su solución. Como el error es a nivel físico, en el hardware, y ni Intel ni ningún otro fabricante de micropocesadores va a reponer los chips afectados², se arreglará a nivel de software, parcheando los sistemas operativos, todos, se implementarán en el kernel controles de seguridad más estrictos, y estos van a ralentizar el funcionamiento de los programas.

¿Todavía no tenemos ningún exploit, verdad?

Esta es precisamente la secuela comentada al principio del artículo; según una estimación inicial, una vez instaladas las actualizaciones, los procesos serán entre un 5% y un 30% más lentos. Aparentemente, cuantas más llamadas haga el proceso al sistema operativo (cualquier acceso a disco, red, etc.) más se verá afectado. Mientras que, por ejemplo, un proceso que hace uso intensivo de la CPU para cálculos apenas se verá afectado, programas como los sistemas gestores de bases de datos (MySQL, Oracle, SQLServer, etc.) o los servidores web lo notarán bastante más. Sin embargo, cabe esperar que progresivamente se vaya optimizando la solución, pero está por ver hasta que punto.

Probablemente, a quien más afecta este fallo de seguridad es a los centros de datos, pues para un atacante es más jugoso poder acceder a la información de miles (o de millones) de usuarios, que colgar en una web un código Javascript malicioso que pueda acceder a los datos de los procesos en ejecución de nuestro ordenador personal o de nuestro móvil. Paradójicamante, también es a ellos a quienes más va a perjudicar la solución al ser los mayores consumidores de tiempo de CPU. A medida que vayan actualizándose las máquinas, es factible que notemos como se ralentizan las webs y diferentes servicios en la nube.

Por supuesto, los fabricantes de microprocesadores también se verán afectados, especialmente Intel, cuyas CPU son vulnerables a ambos fallos. Si finalmente deben modificar el funcionamiento de la ejecución especulativa, todas las existencias almacenadas ya no sirven, las líneas de producción también deberán ser modificadas, etc. En definitiva, pérdidas millonarias en todo el sector. Está por ver en qué queda todo.

Editado el 10/1/2018:

Anoche, en una actualización que aparentaba ser cotidiana del Ubuntu 16.04 que tengo en mi ordenador de sobremesa, se instaló el kernel 4.4.0-108; al reiniciar el sistema, el fallo fue estrepitoso y tuve que purgar esta versión para regresar a la 4.4.0-104. El objetivo de esta actualización del kernel era solucionar la vulnerabilidad Meltdown; cuyas consecuencias, por cierto, siguen sorprendiendo, pues rara vez fallan estas actualizaciones.

Editado el 12/1/2018:

• Ya existe una prueba de concepto para Meltodown, se encuentra en este repositorio de Github.
• En cuanto a la actualización del kernel de Ubuntu, parece ser que la versión 109 funciona correctamente y soluciona la vulnerabilidad.