Spectre: 4 años después del descubrimiento de la vulnerabilidad

Han pasado cuatro años desde la primera publicación de la investigación sobre Spectre y Meltdown, vulnerabilidades de hardware en los procesadores modernos. Desde entonces, los investigadores han descubierto varias fallas similares, que son potencialmente capaces de filtrar datos confidenciales. También mostraron ejemplos de ataques que utilizan estas vulnerabilidades, aunque es poco probable que la mayoría de ellos se utilicen en activo. En esta publicación, analizamos el estado actual de estos problemas de hardware y su uso potencial para el ataque a las empresas.

Las muchas variantes de Spectre

El anuncio original de agosto del 2018 reveló tres vulnerabilidades: Spectre v1 y v2, y Meltdown. Estas vulnerabilidades tienen varias características en común:

• Su explotación suele implicar la ejecución de código malicioso sobre un sistema vulnerable, aunque con pocos privilegios. La opción más peligrosa es un ataque a través de un navegador al visitar una página web “infectada”.
• La explotación práctica requiere una serie de condiciones, en concreto, el código de la aplicación atacada debe permitir la filtración de datos, contar con un dispositivo cuyo acceso haga posible el ataque.
• La filtración de datos en sí se produce a través de canales secundarios. Por ello, la velocidad de la filtración es extremadamente baja.
• Este último argumento es precisamente el que ha despertado especial interés en este trabajo científico aparentemente teórico.

Este último argumento es precisamente el que ha despertado especial interés en este trabajo científico aparentemente teórico. En todos los casos, los investigadores explotaron el sistema de predicción de ramas. Este mecanismo se introdujo hace más de 20 años y permite acelerar el rendimiento al ejecutar un conjunto de instrucciones incluso antes de una solicitud explícita para su ejecución desde el programa. Si la predicción es correcta, los recursos del procesador se utilizarán de manera más eficiente. Si la predicción es incorrecta, los cálculos simplemente se descartan.

Una prueba de concepto sobre Spectre v1 mostró que el procesador leerá datos a los que el programa debería quedar inaccesible. Se almacena en el caché y se puede recuperar desde allí a través de canales laterales. Este mecanismo se consideraba seguro, ya que la lectura errónea de ese “secreto” no se transmitía al programa. Pero los investigadores han encontrado formas de leer indirectamente esos datos.

Tras la publicación del trabajo sobre Spectre y Meltdown, se descubrieron otras vulnerabilidades similares. Los investigadores continúan buscando nuevos métodos para extraer datos secretos mediante la explotación de las vulnerabilidades de los procesadores. Esta tabla de Intel enumera más de 20 de estos problemas, además de los tres originales.

Cómo luchar contra Spectre

Teóricamente, hay tres formas de hacer que la vulnerabilidad de un procesador sea menos explotable: los proveedores pueden emitir una actualización de microcódigo para los procesadores existentes, modificar nuevas CPU o intentar resolver el problema a través de las actualizaciones de software.  A menudo, para una auténtica mitigación del problema resulta necesaria una combinación de actualizaciones de firmware y software. El nuevo microcódigo que cubre algunas de las vulnerabilidades está disponible para los procesadores Intel desde la generación Haswell 2013. Las soluciones de hardware se implementaron por primera vez en la octava generación de procesadores Intel, así como en las CPU Zen 2 de AMD.

Las soluciones de software pueden ser bastante complejas: como ejemplo, puedes revisar las posibles modificaciones en el kernel de Linux contra Spectre v1 y v2. Se debatieron una amplia gama de medidas, dependiendo de las metas y objetivos de un sistema en particular, incluida la desactivación completa de la ejecución de código especulativo con graves consecuencias para el rendimiento de la CPU.

Para la mayoría de las organizaciones cuyo modelo de negocio depende del rendimiento de una gran flota de servidores, la caída del rendimiento será el impacto más notable de las medidas contra Spectre. Un punto de referencia relativamente reciente en el sitio web de Phoronix, que examina el rendimiento de varias aplicaciones de servidor, muestra una disminución del rendimiento de una media del 25 % cuando se habilitan todas las precauciones contra Spectre en el sistema operativo Linux.

Los ataques prácticos y las pruebas de concepto

A pesar de la gran cantidad de tipos de ataque, la amenaza del robo de datos con Spectre sigue siendo teórica. Aunque cada investigación contiene algún código que demuestra la filtración, esto no significa que este código pueda usarse contra un sistema real. Las limitaciones típicas de estas demostraciones o pruebas de concepto son las siguientes:

• Demuestran una filtración aleatoria de datos. Puede que no tenga un valor práctico, es solo información aleatoria a la que el atacante no ha tenido acceso previamente.
• Los investigadores crean las condiciones ideales para el ataque. Por ejemplo, tienen acceso ilimitado al sistema. En este caso, no es necesario utilizar métodos complejos para la exfiltración de datos.
• Demuestra una violación de datos real, pero en condiciones muy poco probables.

El trabajo teórico más impresionante (en lo que respecta a las posibles consecuencias) es el ataque NetSpectre.  Los investigadores lograron demostrar la explotación remota con exfiltración de datos a una velocidad de 15 a 60 bits por hora. Las limitaciones del ataque quedan claras: baja velocidad de transmisión de datos, los datos exfiltrados contienen una gran cantidad de tráfico basura, además de que el código debe quedar vulnerable en el servidor atacado y se debe actuar “en el lugar correcto” para lograr el éxito.

El año pasado se mostraron dos ataques prácticos, lo más cerca posible de las condiciones en activo. En marzo, Google mostró un concepto de leaky.page: una página web que puede extraer datos de la memoria RAM. En septiembre, se demostró un ataque Spook.js en la última versión (en el momento de la investigación) de Google Chrome (92) con protección Spectre (aislamiento de páginas web en procesos de navegador aislados). Este método permitió el robo de datos reales: los investigadores accedieron a las credenciales de una red social, a los datos del administrador de contraseñas y a una imagen cargada por un usuario en una nube privada. Pero en todos estos casos, el éxito de la operación requería contar con una página “infectada” ubicada en el mismo dominio. Por ejemplo, robar una contraseña de Tumblr implica cargar un código Javascript malicioso en otra página de la misma red social.

Entonces, ¿qué peligros supone esta amenaza?

Spook.js fue neutralizado con un parche de software para el navegador Google Chrome. Por lo tanto, en este momento, no existe una amenaza inmediata de explotación de las vulnerabilidades de Spectre en condiciones reales. Todos los ataques conocidos son extremadamente complejos y requieren las mejores habilidades por parte del atacante.

La mayoría de las pruebas de concepto realistas ya han sido parcheadas e, incluso sin parches, su explotación requiere un gran conjunto de condiciones. Aunque no se han confirmado los informes de los medios sobre “los exploits de Spectre” reales, los proveedores de seguridad añadieron herramientas para detectar ataques conocidos por si acaso, por lo que lo más probable es que los mecanismos de detección de malware existentes puedan ayudar a proteger tu empresa.

Sin embargo, no debemos ignorar por completo a Spectre: es importante que la investigación continúe. Existe una pequeña posibilidad de que, con el tiempo, se descubra el “peor escenario”: un ataque que no requiera la instalación de malware y que permita la filtración de datos sin dejar rastro.

En teoría, se puede realizar un ataque dirigido utilizando vulnerabilidades del hardware si el valor de los datos robados lo justifica. La protección contra tales riesgos requiere inversiones importantes para identificar posibles vectores de ataque, seguir las recomendaciones de los desarrolladores de sistemas operativos o implementar la protección, incluso a costa de una caída importante del rendimiento. Pero para la mayoría, incluso para las grandes empresas, basta con confiar en los desarrolladores de software y sistemas operativos, fabricantes de procesadores y soluciones de seguridad.