Tras hablar el otro día sobre Meltdown, uno de los dos ataques que afectan a las CPUs de nuestros dispositivos (principalmente a los Intel, pero también a algunos de otros fabricantes) y explicar en qué consistía exactamente (podéis leer el análisis pulsando aquí), hoy pasamos a su hermano mucho más peligroso y rebelde: Spectre.
De él hay que entender tres cosas: la primera es que de las tres posibles vulnerabilidades que explotan los agujeros de seguridad Meltdown y Spectre, solo una (y una variación descubierta por ARM) afecta a Meltdown y los otros dos son Spectre. La segunda es que Spectre es tan amplio en su espectro que parchear todos sus posibles casos podría ser considerado casi imposible. Es un fallo de diseño hardware y como tal la forma de tratar con él es diferente y lo único que se puede hacer es prevenir los ataques que podrían hacerse a través de Spectre uno a uno según se vayan descubriendo. La tercera y última: Spectre afecta a todos los procesadores de todos los fabricantes que se han hecho en los últimos 23 años. Sin excepción.
La culpa de Spectre la tiene una técnica usada por los procesadores desde el año 1995, que empezó a usarse por Intel en los Pentium Pro junto a la ejecución fuera de orden, responsable principal del ataque Meltdown. Esta técnica es la conocida como ejecución especulativa. ¿En qué consiste? En aprovechar las pausas de la CPU para ejecutar instrucciones que no necesitamos pero especulamos que podríamos necesitar en base al flujo de código. De esta forma, cuando alguna de esas operaciones especuladas se quiere ejecutar, ya estaría ejecutada y nos ahorramos el cálculo porque se hizo en un momento que la CPU no hacía nada. Esa es la esencia.
La ejecución especulativa es un paso más allá del concepto de caché que todos conocemos y se basa en el propio flujo de una app. Un ejemplo simple: imagina una sentencia if. Dicha sentencia tiene dos posibles caminos de ejecución en base a una condición. Pues bien, una CPU moderna con este sistema ejecuta de forma especulativa las dos posibles salidas del if aprovechando pausas de proceso (estados llamados idle) que tiene la CPU. De esta forma, lo que pase en todos los casos del if ya está ejecutado y su resultado guardado en una caché.
Cuando llega la instrucción que tiene que ejecutarse tras evaluar el if a la CPU se compara con aquellas que se han ejecutado especulativamente, y si son la misma se recoge el resultado de la caché y se obvia la ejecución. En caso que no sean iguales, el resultado se descarta y se borra. La ventaja es que la ejecución previa (o especulativa) se ha hecho en tiempos de pausa donde la CPU no hacía nada más. Y además, una CPU es capaz de descartar instrucciones sin coste de proceso. Por lo tanto es una buena forma de optimizar la carga de trabajo de la CPU sin penalizar por ello con trabajo extra.
Como podemos imaginar, esta técnica funciona gracias a la ejecución fuera de orden, que como ya vimos al hablar de Meltdown, permite ejecutar instrucciones fuera de su orden natural secuencial para optimizar el rendimiento.
Mientras Meltdown permitía a cualquier aplicación leer la memoria del kernel de la CPU, Spectre es mucho más peligroso porque permite romper las barreras que delimitan las zonas de memoria de cada app que se ejecuta en el sistema. De esta forma, una app podría leer libremente la memoria de otras apps y obtener toda su información rompiendo una de las bases de seguridad de las propias CPUs.
¿Cómo se hace? Simple. El fallo está en que se puede trucar la ejecución especulativa para poner instrucciones que una CPU ejecute para una app cualquiera, no aquella que genera dichas instrucciones. Y si esas instrucciones leen datos para ser ejecutadas de forma previa, ya tenemos acceso a todo lo que queramos de cualquier app. Básicamente, el fallo no es que podamos leer la memoria de otras apps, es que podemos ejecutar cualquier instrucción dentro de esa cola especulativa como si fuera de otra app y, por lo tanto, hacer lo que queramos.
Como las instrucciones que colemos a la CPU nunca van a coincidir con las instrucciones que luego ejecute la app, estas serán borradas. Pero mientras la CPU descarta las ejecuciones, tenemos acceso a cualquier dato que queramos leer a través de la caché. Esa es la base.
Lo más peligroso de Spectre es que existen dos formas de inyectar estas instrucciones en la CPU para acceder a cualquier aplicación que se esté ejecutando. La primera es mediante la ejecución de código nativo en el mismo sistema. De forma local. Alguien sentado en una máquina a partir de un terminal puede conseguir explotar esta vulnerabilidad. Pero insistimos, hay que tener acceso físico a la máquina (o remoto iniciando sesión en la misma).
Pero la segunda es crítica, porque a través de Javascript se puede pasar por encima de la seguridad del sandbox del navegador y ejecutar instrucciones que lean información de este que sea sensible, como claves o cualquier otro tipo de dato. Esta última es la que ha parcheado Apple con sus últimas actualizaciones de iOS y macOS centradas en el motor WebKit que usa Safari.
La primera alarma saltó cuando se supo que mitigar (que no parchear) el efecto de corregir Spectre podría costar tiempo de proceso a los procesadores. En un principio se habló de valores que podían llegar a un 35% del total. Finalmente se ha visto que en la mayoría de casos, la bajada en el rendimiento es casi insignificante dentro de un uso real, rondando un 5%.
Pero, ¿por qué se hace el equipo más lento? Básicamente porque se usa una técnica llamada retpoline que consiste en poner un proceso que evalúe aquellos usos que se hagan de la ejecución especulativa para asegurar que pertenecen al proceso donde van a ser ejecutados. Para ello hay que replicar una parte de la funcionalidad del procesador por software, el cual obviamente es más lento, y por eso la incidencia.
No obstante, hay procesadores como la gama Haswell o anteriores de Intel, que pueden verse más perjudicados porque cuanto más antigua es la CPU más le va a costar hacer este proceso en tiempo real que controla estos casos. También Windows 7 u 8 pueden verse más afectados que Windows 10 ya que tienen procesos a nivel de kernel (como el renderizado de las fuentes de texto) que se ven significativamente perjudicados y hacen los sistemas mucho más lentos.
Siempre va a depender del sistema operativo y su estructura a la hora de implementar estos parches. En el caso Apple, se informó oficialmente que la mitigación de Meltdown se hizo en iOS 11.2, macOS 10.13.2 y tvOS 11.2 (watchOS no está afectado por estos errores y no ha necesitado parche). Implementaron estos parches en diciembre y ninguno de los test de velocidad tanto de CPU como de uso de web indicaron una bajada realmente perceptible del rendimiento de los equipos.
Spectre, mitigado hace unos días con iOS 11.2.2 y un parche de seguridad suplementario para WebKit publicado en todos los sistemas actualmente con soporte de Apple como High Sierra, Sierra o El Capitan, han dado una bajada de rendimiento del 2,5% en el motor de Javascript con respecto a antes de aplicar el parche. Por lo tanto, en cuanto a Apple podemos estar tranquilos que el rendimiento no se verá afectado de forma significativa (al menos por ahora).
Lo que está claro es que nunca estamos seguros. Los fallos de hardware y software pueden aparecer en cualquier momento y mi gran pregunta es si no ha habido personas o instituciones que lleven 23 años aprovechando estos fallos u otros sin ningún tipo de idea por nuestra parte.
Por lo tanto, la mejor seguridad es usar el sentido común, no navegar por sitios de dudosa procedencia, no instalar ningún programa que no venga de fuente confiable y hacer un uso coherente de la tecnología. Nunca estaremos seguros, pero desde luego estaremos más prevenidos. Un saludo y Good Apple Coding.