Meltdown y Spectre, o los riesgos heredados del bajo nivel

spectre vulnerability

En Mayo del año pasado dedicaba una pieza para explicar la importancia que tenía vigilar cómo funciona el hardware de nuestros dispositivos.

Es, de facto, una asignatura pendiente para muchos de los que se dedican nos dedicamos a la seguridad. Tendemos a centrarnos en el software, habida cuenta de que nos es más inmediato (la mayoría venímos del mundo de la programación) y las barreras de entrada suelen ser, tradicionalmente, más leves.

Pero basta que alguien encuentre un fallo de seguridad gordo en alguno de los componentes de nuestros dispositivos para poder, según el caso, hasta bypasear cualquier control de seguridad que se haya establecido a nivel de software.

De ahí, de hecho, que desde hace unos años la mayoría de fabricantes hayan movido ficha por posicionarse como una pieza más de seguridad con sus chips. El procesador que montan hoy en día nuestros dispositivos opera ya con controles propios, y tenemos ejemplos que así lo atestiguan, como el uso que hace Intel de sus procesadores para la identificación del usuario o la cada vez más habitual aparición de chips adicionales en dispositivos móviles que gestionan de forma aislada procesos de verificación.

En las últimas horas ha quedado patente cómo, lo que a priori era un fallo de seguridad bastante grave en la mayoría de chips de Intel creados en la última década, ha acabado por transformarse en un problema de seguridad que prácticamente afecta a cualquier dispositivo actual de electrónica de consumo.

Meltdown y Spectre son los dos nombres “comerciales” con los que se han dado a conocer sendas vulnerabilidades, y por aquí, como no podía ser de otra manera, voy a intentar explicar de forma sencilla y directa qué supone cada uno, qué diferencias hay entre ellos y qué podemos hacer para mitigar sus efectos en cada uno de los sistemas operativos.

Comencemos:

Qué es Meltdown

  • Su nombre técnico es CVE-2017-5754.
  • La vulnerabilidad afecta a prácticamente todos los procesadores de Intel fabricados en la última década.
  • Tiene solución vía parche (más tarde veremos cuándo sale cada una), pero podría conllevar bajones de rendimiento (entre un 5 y un 30%, según el procesador), [ACTUALIZACIÓN] aunque según Google se podría solucionar sin pérdidas.

Hablamos de un error de diseño en las CPUs de Intel que permite potencialmente a un atacante acceder a datos de la memoria del sistema. Según recogía The Register (EN) hace un par de días:

Meltdown rompe el aislamiento fundamental entre las aplicaciones de usuario y el sistema operativo. […] Si el equipo tiene un procesador vulnerable y ejecuta un sistema operativo sin parchear, no es seguro trabajar con información confidencial sin la posibilidad de que se filtre información confidencial.

En este vídeo se ve cómo es posible dumpear la memoría del sistema aprovechándose de la vulnerabilidad:


Ver en Youtube (EN)

En este otro, cómo es posible leer en texto plano una contraseña almacenada en memoria:


Ver en Youtube (EN)

Solo se salvan de la quema los procesadores Intel Itanium e Intel Atom antes de 2013.

Gracias al ataque, es posible llegar a obtener acceso a las contraseñas de un administrador de credenciales o de un navegador, así como información y contenido que el sistema almacene (fotos, correos, documentos…).

 

Por aquí tiene acceso al paper de Meltdown (EN/PDF) para profundizar en su funcionamiento.

Qué es Spectre

  • Está formada por dos CVEs: CVE-2017-5753 y CVE-2017-5715.
  • La vulnerabilidad afecta a prácticamente todos los procesadores en el mercado.
  • No hay una solución directa, habida cuenta de que más que un error de diseño es un paradigma de funcionamiento que hoy en día, y como veremos, se ha quedado obsoleto a nivel de seguridad.

Aquí están dos de sus principales diferencias. Mientras Meltdown afecta (por ahora) solo a chips de Intel, Spectre afecta a prácticamente cualquier procesador. Y mientras Meltdown ataca a la memoria del sistema, Spectre lo hace a la memoria de cualquier aplicación.

Esto significa que implementar un ataque mediante Spectre es bastante más complejo que hacerlo mediante Meltdown… pero, por supuesto, muchísimo más dañino (en la práctica dilapida cualquier control de seguridad que tengamos habilitado a nivel de software):

Spectre rompe el aislamiento entre diferentes aplicaciones. Permite a un atacante engañar a los programas sin errores, que siguen las mejores prácticas, para filtrar su contenido. De hecho, los controles de seguridad implementados hoy en día en realidad aumentan la superficie del ataque y pueden hacer que las aplicaciones sean más susceptibles a Spectre.

El ataque se aprovecha de la manera de procesar que prácticamente es estándar en la industria denominada ejecución especulativa (EN). Bajo este principio, el procesador realiza cálculos intentando adelantarse a las necesidades del usuario. En caso de que al final sean necesarios, ya lo tiene en memoria y por tanto es casi inmediato. Y en caso contrario simplemente se obvia.

¿Cuál es el problema entonces? Que para agilizar los procesos, en estas ejecuciones de código no se realizan controles de seguridad, por lo que un atacante podría forzar la ejecución de código malicioso bajo una ejecución especulativa, sin tener que pasar los controles esperables, accediendo a la memoria de la aplicación objetivo.

Ahí está el quid de la cuestión. Realmente el fallo está en cómo operan los procesadores de la actualidad, y la solución más que un parche pasaría por cambiar el paradigma y establecer controles de seguridad también en ejecuciones especulativas, lo que lleva asociado una pérdida de rendimiento (más pasos dentro de cada ejecución).

Hay, no obstante, algunos acercamientos interesantes que se basan en minimizar la capacidad de un atacante a la hora de medir intervalos de tiempo de manera precisa (algo necesario para acceder a una parte específica de la memoria).

Si el atacante no puede conocer el instante exacto en el que se ha producido esa escritura en memoria, en la práctica se minimiza el impacto que podría tener este tipo de ataques… sin tener que buscar (o peor aún, implementar) otro paradigma distinto. Cosa que ya le digo que no es viable en corto/medio plazo.

Por aquí tiene acceso al paper de Spectre (EN/PDF) para profundizar en su funcionamiento.

¿Es tan grave como parece?

Sí y no. Me explico.

Tenemos que considerar que estamos a principios de año, y que por tanto, al estar todo parado, la mayoría de medios se han hecho eco de esta noticia de la forma más catastrofista posible, habida cuenta de que lo apocalíptico es lo que más vende, y que para colmo les sirve para llenar editoriales unos cuantos días.

Las vulnerabilidades son graves, principalmente porque en el caso de Spectre no hay una solución como tal, y en el de Meltdown va a llevar asociada una bajada de rendimiento que claramente no es de gusto para nadie, pero no se va a acabar el mundo. Como tampoco nos ocurrió con WannaCry, ni con Petya/NotPetya ni con Stuxnet.

Ahora bien, los mayores afectados son los microprocesadores de Intel. AMD, como explicaré más adelante, ya ha informado que apenas se ve afectado por ello, y de ARM sabemos que al menos hay dos modelos afectados y tampoco es que sean 100% vulnerables a todos los ataques que de aquí se derivan.

Además, hay que tener en cuenta que esa bajada de rendimiento, que podía ser de hasta el 30% en Windows y 17% en Linux según algunos análisis iniciales, para la amplia mayoría de dispositivos no subirá a los dos dígitos, y eso, sinceramente, ni lo vamos a notar los usuarios de a pie. Y que solo se produce cuando el parche se aplica en un dispositivo que lleva el procesador oportuno. No será algo genérico, como he leído por ahí, indistintamente de si utilizamos Intel o AMD, estamos o no afectados.

[ACTUALIZACIÓN] Eso presuponiendo que la propuesta de Google caiga en saco roto. Hace apenas unas horas Google aseguraba que sus ingenieros habían sido capaces de parchear Meltdown sin recurrir a la pérdida de rendimiento asociado al aislamiento de páginas de tables del kernel, que es lo que hasta el momento los parches estaban haciendo.

La técnica recibe el nombre de ReptOnline, y por aquí explican su funcionamiento (EN).

Lo que sí me gustaría dejar claro es que tanto en Meltdown como Spectre el verdadero riesgo no radica en que alguien nos quiera hacer un ataque dirigido a nuestros dispositivos. Esto, para el grueso de la sociedad, es algo que seguramente nunca nos va a pasar. El verdadero problema reside en que ese ataque se podría hacer a un servicio de almacenamiento en la nube o a los servidores de una compañía, exponiendo potencialmente todos los documentos o información que allí se está procesando.

Por otro lado, hay que tener en cuenta que gracias a estos ataques se puede acceder a contenido informático que esté en ese mismo momento en memoria. Es decir, que en ese mismo momento haya sido utilizado por el usuario (Meltdown) o pedido de alguna manera un tanto más rebuscada por el atacante (Spectre).

Para terminar, hablamos de tipologías de ataques muy complejas, en las que como hemos visto tiene que interferir también el usuario, que requieren que previamente se pasen los controles de seguridad implementados en el sistema para infectar a la víctima y que tienen un alcance limitado a la operativa misma del dispositivo.

¿Es por tanto grave? Pues sí, claro que lo es. Pero vamos a salir de esta. De eso se lo aseguro.

Cómo sé si estoy afectado y parches disponibles

De Spectre ya le digo que prácticamente todos los dispositivos (escritorio y móvil) son vulnerables.

En el caso de Meltdown afecta a todos los dispositivos que monten procesadores Intel desde 1995, a excepción de Intel Itanium e Intel Atom de antes de 2013.

Windows

Windows 10 ya cuenta con una actualización de seguridad (EN) que mitiga el ataque. Eso sí, parece que algunos (EN) han tenido problemas de incompatibilidades con antivirus comerciales, así que ojito con instalarlo a pelo.

Si no le ha llegado, le llegará en las próximas horas (a un servidor le llegó ayer al medio día).

Como siempre, lo recomendable es primero crear un punto de restauración.

Android

El 5 de enero se publicará la actualización de seguridad (EN) que minimiza el impacto de estos ataques. Luego ya dependemos que el resto del ecosistema actualice convenientemente para mitigar por completo las vulnerabilidades.

Como suele pasar en Android, la actualización llegará primero llegará a los Pixel, después presumiblemente a los dispositivos con Android One (como el Xiami Mi A1), y ya, si eso…, al resto de dispositivos.

No voy a repetirme en lo de que el mayor problema de Android es precisamente la fragmentación y dependencia a la hora de actualizarse por parte de stakeholders (fabricantes de chips, vendors…). Están trabajando en ello, y si todo sale como marca el timeline, para 2019 quizás ya podamos olvidarnos del problema de la fragmentación. Pero hasta entonces habrá millones de dispositivos que mes tras mes son más inseguros.

MacOS e iOS

[ACTUALIZACIÓN] Apple se acaba de pronunciar oficialmente (EN) justo después de publicar esta pieza.

[ACTUALIZACIÓN 2] Ya ha liberado parches para iOS (EN) y MacOS (EN).

Todos sus dispositivos están de una u otra manera afectados, y como ya se había planteado, la versión 10.13.2 de MacOS High Sierra mitiga parte del problema, aunque se espera una actualización más completa dentro de poco.

Lo que sí es nuevo es que en iOS 11.2 y tvOS 11.2 también habían parcheado el asunto. WatchOS sigue siendo vulnerable.

Safari también es vulnerable, y se espera que en unos días liberen el parche oportuno.

De Spectre, como ya he comentado, no hay parche como tal, sino simplemente herramientas para mitigar el riesgo, que se entiende vendrán en esos parches.

Chrome

El navegador ya cuenta con algunas funcionalidades que minimizan este tipo de ataques, y que vendrán activas por defecto en la próxima actualización de Google Chrome (la 64) esperable para el 23 de enero.

Si le urge, puede activar Site Isolation (EN) desde “chrome://flags/#enable-site-per-process” y dándole a habilitar. Con esto lo que conseguimos es forzar a que cada sitio web aísle en distintos espacios de memoria el contenido, lo que complica las cosas.

Desde Android podemos habilitarlo en “chrome://flags”. También creo conveniente recordar que hablamos de funcionalidades en modo beta, y que por tanto, podrían causar incompatibilidades.

En iOS, y por limitaciones del sistema, todo software de navegación utiliza el motor de Safari, por lo que dependemos nuevamente de los designios de la manzana.

Firefox

La pieza que publicaba Luke Wagner en el blog de Mozilla (EN) es de las más reveladoras (por corta y directa) que he leído estas últimas horas.

Lo que ha hecho Firefox es seguir los pasos de Microsoft con Edge y actualizar la manera en la que funciona la función “performance.now ()”, deshabilitando por defecto “SharedArrayBuffer”. Es, como en el resto de casos, dos maneras de complicar aún más el descubrimiento de espacios de memoria, que es lo que está permitiendo que un atacante pueda robar datos y ficheros a la víctima.

Y está disponible a partir de la versión 57 de su navegador.

También compartía enlace a un paper en el que explican cómo mitigar algunos ataques vía JavaScript que podrían aprovecharse de estas vulnerabilidades (EN/PDF).

Microsoft Edge e Internet Explorer 11

Ambos navegadores vienen parcheados ya en la actualización de seguridad de Windows, y han recurrido básicamente a la misma estrategia de Firefox (EN).

ARM

Al parecer, y según los fabricantes, la mayoría de procesadores ARM no están afectados, o lo están a un nivel bastante bajo. En el whitepaper (EN/PDF) que han liberado estos días hablan de los Cortex-A57 y Cortex-A72, presentes en la mayoría de SoCs actuales.

También han liberado parches para Linux (EN).

Y esto es, por ahora, la información que he ido encontrando al respecto. Iré actualizando la página conforme vaya saliendo más contenido trascendente.

 

________

Si el contenido que realizo le sirve en su día a día, piense si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.

hazme patrono pabloyglesias