¿Qué son Spectre y Meltdown? Esto es lo que necesita saber.

Los recientes reportes de prensa hablan de una nueva forma de amenaza a la seguridad en la que se ven implicados atacantes de piratería informática que explotan características comunes de microprocesadores modernos (también conocidos como aka chips) que afectan a nuestras computadoras, tabletas, smartphones y otros gadgets. Estos ataques conocidos como “Meltdown” y “Spectre” son el centro de atención del mundo.  La gente está (bastante) preocupada, y por supuesto es muy importante aplicar todas las actualizaciones de software necesarias que han sido producidas y puestas a disposición cuidadosamente. Los líderes tecnológicos, incluido Red Hat, están trabajando juntos para abordar estas hazañas y minimizar el riesgo de posibles ataques.

En Red Hat, hemos estado trabajando en mitigaciones para posibles ataques bajo embargos de seguridad estándar de la industria, implementando pequeños equipos específicos que operan sobre una base de "need to know" afín de prepararse antes de la divulgación pública.  Tuve la suerte de colaborar en la mitigación de Spectre y Meltdown, alternativamente conocidos como las variantes 1,2 y 3 de una familia de ataques similares revelados por Google Project Zero en un blog publicado el 3 de enero. Durante nuestros mutuos esfuerzos, reprodujimos Meltdown (variante 3) en nuestros laboratorios, y examinamos otras variantes, mientras trabajamos en conjunto con muchos de nuestros socios de hardware de confianza en mitigaciones.

Si bien tenemos una sólida comprensión de estas vulnerabilidades y el análisis actual de los factores contribuyentes, así como parches para mitigar su impacto potencial, seguiremos colaborando con nuestros socios, clientes e investigadores en esta situación. Además, nos gustaría ayudar a otros a que entiendan estos temas complejos, idealmente con lenguajes y términos que no requieren que el lector sepa o haga parte del negocio de diseño de chips.  Para aquellos que deseen obtener detalles técnicos en profundidad, los documentos de investigación originales y las publicaciones asociadas están disponibles en http://meltdownattack.com/ y http://spectreattack.com/, pero también vale la pena tener en cuenta que muchos de los involucrados en la identificación de estas hazañas tienen una amplia experiencia en la investigación académica de arquitectura informática. Al menos uno de ellos, recibió un doctorado en un área relacionada el año pasado. Así que no se sienta mal si toma tiempo para examinar los detalles técnicos en profundidad; este asusto es en realidad muy complejo y detallado.

Para continuar, entendamos un poco sobre la "ejecución especulativa" mirando una analogía cotidiana.

Supongamos que un cliente regular visita la misma cafetería y pide la misma bebida de café cada mañana. Con el tiempo, el cliente conoce a los baristas, que se familiarizan con su pedido habitual. En busca de ofrecer un buen servicio, y evitar que el cliente permanezca en la fila por mucho tiempo, los baristas deciden eventualmente comenzar a preparar el pedido tan pronto el cliente entra y los saluda. Pero resulta que un día, el cliente decide cambiar su pedido.  Ahora el barista tiene que tirar el café que ha preparado previamente y hacer uno nuevo mientras el cliente espera.

Llevando esta analogía más lejos, suponga que los baristas ya conocen el nombre del cliente y les gusta escribir su nombre en la taza con un marcador permanente. Cuando preparan especulativamente la bebida habitual, escriben el nombre del cliente en la taza. Si el cliente viene con un pedido diferente, la taza se tira junto con su contenido. Pero al hacer esto, la información personal del cliente es brevemente visible para los que estén mirando en ese momento.

Este escenario de la cafetería implica especulación.  El personal no sabe con seguridad cuando el cliente apenas llegue, si va hacer un pedido de un café americano o con leche; pero saben a partir de datos históricos lo que el cliente ordena generalmente y hacen una suposición educada para evitar que el cliente espere. Una especulación similar ocurre a lo largo de nuestra vida diaria porque tales suposiciones a menudo resultan ser verdaderas, y como resultado podemos hacer más en la misma cantidad de tiempo. Así es con nuestras computadoras. Utilizan una técnica conocida como "ejecución especulativa" para realizar ciertas operaciones de procesamiento antes de que se sepa con certeza que esas operaciones serán necesarias, partiendo de la premisa de que estas suposiciones a menudo resultan en un ahorro de tiempo.

En el caso de las computadoras, la ejecución especulativa se utiliza para decidir qué hacer cuando se enfrenta a una prueba como la siguiente: "si A, hace esto; de lo contrario hágalo".  A esto le llamamos condiciones de pruebas, y el código que se ejecuta como resultado es parte de lo que llamamos "un salto condicional". Un salto por sí solo, significa una sección del programa que elegimos ejecutar en respuesta al resultado de la condición. Los chips de las computadoras modernas tienen sofisticados "predictores de saltos" (branch predictor en inglés) que usan algoritmos sofisticados para determinar cuál es el resultado probable de la prueba condicional mientras se sigue calculando esa prueba. Mientras tanto, ejecutan de forma especulativa código en el salto que parece ser más probable que se ejecute. Si la suposición resulta ser correcta, el chip parece ejecutarse más rápido que esperar a que se complete la prueba. Si la suposición es incorrecta, el chip tiene que lanzar cualquier resultado especulativo y ejecutar el otro salto.  Los predictores de saltos a menudo aciertan casi al 100%.

Como puede ver, el beneficio potencial de rendimiento de un chip que ejecuta especulativamente la parte del código correcta es significativo. De hecho, la ejecución especulativa es una de las muchas optimizaciones que han ayudado a acelerar drásticamente nuestras computadoras en las últimas dos décadas. Cuando se implementa correctamente, el beneficio de rendimiento obtenido es considerable. La fuente de los problemas recién identificados proviene de los intentos de diseño de los chips para optimizar más allá, asumiendo que el proceso de especulación es una caja negra que es completamente invisible para los observadores externos (o los intrusos).

La inteligencia convencional de la industria consistía en que lo que ocurriera durante el proceso de especulación (conocido como una "ventana de ejecución especulativa") bien era confirmado más tarde y los resultados eran utilizados por el programa, o no se utilizaba y se descartaba por completo. Pero resulta que hay maneras en que los atacantes pueden ver lo que ocurre dentro de la ventana de especulación para así manipular el sistema. Un atacante también puede controlar el comportamiento de los predictores de saltos para que ciertas secuencias de código se ejecuten de modo especulativo que en un principio nunca deberían haberse ejecutado. Esperamos que estas vulnerabilidades y otros defectos similares que podrían explotar la ejecución especulativa, conduzcan a cambios fundamentales en la elaboración de los futuros chips para que se pueda tener una ejecución especulativa; sin riesgos de seguridad.

Profundicemos un poco más en los ciberataques, comenzando con Meltdown (variante 3) que recibió mucha atención debido a su amplio impacto. En esta forma de ataque, el chip es manipulado para cargar datos seguros durante una ventana de especulación de tal manera que un atacante no autorizado puede verlos más tarde. El ataque se basa en una práctica comúnmente utilizada en toda la industria que consiste en separar la carga de datos en memoria del proceso de verificación de permisos. Nuevamente, el equipo de inteligencia convencional de la industria operaba bajo la suposición de que todo el proceso de ejecución especulativo era invisible, por lo que separar estas piezas no era visto como un riesgo.

En Meltdown, un salto de código cuidadosamente diseñado, se encarga primero de ejecutar algún código de ataque especulativamente. Este código carga algunos datos seguros a los que el programa normalmente no tiene acceso. Debido a que esta se produce de forma especulativa, la comprobación de permisos sobre ese acceso se realizará en paralelo (y no fallará hasta el final de la ventana de especulación), y como consecuencia, una memoria interna especial de chip conocida como caché se carga con los datos privilegiados. A raíz de ello, se utiliza una secuencia de código cuidadosamente construida para realizar otras operaciones de memoria basadas en el valor de los datos privilegiados. Si bien los resultados normalmente evidentes de estas operaciones no son visibles tras la especulación (que en última instancia se descarta), se recurre a una técnica conocida como "análisis de canal lateral de caché" para determinar el valor de los datos seguros.

Mitigar el Meltdown implica cambiar la forma en que se gestiona la memoria entre el software de la aplicación y el sistema operativo. Incorporamos una nueva tecnología, conocida como KPTI (Kernel Page Table Isolation), que separa la memoria de forma que los datos seguros no se pueden cargar en las cachés internas del chip mientras se ejecuta el código de usuario. Tomando medidas adicionales, cada vez que el software de aplicación pide al sistema operativo que haga algo en su lugar, lo que llamamos "system calls", resulta en un éxito total de rendimiento.  El grado de rendimiento varía aproximadamente en función de la frecuencia con la que una aplicación necesita utilizar tales servicios del sistema operativo.

El ataque Spectre consta de dos partes. La primera (variante 1) tiene que ver con la violación de "control de límites" (bounds checking en inglés). Una vez más, cuando se ejecuta el código especulativamente, el chip puede cargar algunos datos que luego se utilizan para localizar una segunda pieza de datos. Como parte de una optimización del rendimiento, el chip podría intentar cargar especulativamente la segunda pieza de datos antes de que haya comprobado que la primera se encuentra dentro de un rango definido de valores. Si esto sucede, es posible programar que el código se ejecute de forma especulativa y que los datos no se lean en las cachés del sistema, de donde se puede extraer utilizando un ataque de canal lateral similar al que se ha comentado anteriormente.

Mitigar la primera parte de Spectre implica incorporar lo que llamamos "load fences" en todo el kernel. Estos impiden que el hardware de especulación intente realizar un segundo load basado en el primer load.  Éstos requieren cambios pequeños, triviales y no particularmente que afecten el rendimiento a nivel de la fuente del kernel. Nuestro equipo de utilidades ha desarrollado algunas herramientas y ha trabajado con otros para ayudar a determinar dónde se deben posicionar estas últimas.

La segunda parte de Spectre (variante 2) es de cierto modo la más interesante.  Tiene que ver con "entrenar" el hardware predictor de salto. Esto con el objetivo de favorecer la ejecución especulativa de piezas de código sobre las que debería estar ejecutando. Una optimización de hardware común es basar el comportamiento de una opción de salto dada en la posición en memoria del propio código de salto. Desafortunadamente, la forma en que se almacena esta posición en memoria no es única entre una aplicación y el kernel del sistema operativo. Esto permite que el predictor sea entrenado para ejecutar especulativamente cualquier código que el atacante desee. Al elegir cuidadosamente un "gadget" (código existente en el kernel que tiene acceso a datos privilegiados) el atacante puede cargar datos sensibles en las cachés de los chips, donde el mismo tipo de ataque de canal lateral sirve una vez más para extraerlo.

Uno de los mayores problemas planteados por esta segunda parte de Spectre es su potencial para explotar la línea divisoria entre el kernel del sistema operativo y un hipervisor, o entre diferentes máquinas virtuales que se ejecutan en el mismo hardware subyacente. El predictor de salto puede ser entrenado por una máquina virtual para generar código privilegiado en el hipervisor (u otra instancia de máquina virtual) para que acceda a datos confiables del hipervisor que pueden ser extraídos usando un canal lateral. Esto supone un riesgo significativo para los entornos cloud privados y públicos que ejecutan servidores no actualizados.

Mitigar esta segunda parte de Spectre requiere que el sistema operativo (deshabilite selectivamente) el hardware de predicción de salto cuando un programa solicite servicios de sistema operativo (system call) o hipervisor, de modo que cualquier intento de código malicioso para entrenar al predictor no se transmita al kernel del sistema operativo, el hipervisor o entre máquinas virtuales no seguras que se ejecutan en el mismo servidor. Este enfoque funciona bien, pero tiene una penalización de rendimiento que no es insignificante. Los parches de Red Hat implementarán por defecto el cambio de seguridad y aceptarán el impacto de rendimiento, pero también hemos incluido a los administradores del sistema para que puedan activar o desactivar esta opción (y todas las configuraciones implementadas).  Aparte de eso, estamos trabajando con la comunidad Linux más grande para reducir este impacto con el paso del tiempo, examinando alternativas para desactivar la predicción de saltos. Una posible alternativa es conocida como "retpolina", una forma especialmente ideada de ejecutar el código del kernel del sistema operativo que previene la especulación incorrecta del salto.

Esperamos que este post les haya aportado un poco más de información sobre estos sofisticados ataques. Explotarlos no es nada trivial, las mitigaciones son posibles, y aunque ahora hay algunos ejemplos disponibles en línea para Meltdown (variante 3), los parches están disponibles a través de actualizaciones enviadas por los principales proveedores como Red Hat. Con el tiempo, es posible que se descubran vulnerabilidades adicionales y similares, así como códigos de ejemplo para explotarlas en línea, por lo que es importante mantenerse al día con las correcciones de seguridad tan pronto salgan a la luz.

Es importante tener en cuenta que estos son los primeros días después del hallazgo de una especie completamente nueva de vulnerabilidades de seguridad del sistema y, como resultado, las mitigaciones y los consejos de mejores prácticas pueden cambiar con el tiempo. Continuaremos trabajando con los líderes de la industria y las comunidades de código abierto para proteger a nuestros clientes de estas y otras vulnerabilidades conocidas y hacer que Linux sea aún más resistente contra ataques como los de Meltdown y Spectre. En los próximos meses, publicaremos más información sobre este proyecto y mantendremos a los clientes informados sobre cualquier orientación relacionada con nuestros productos. Para obtener más información, visite https://access.redhat.com/security/vulnerabilities/speculativeexecution