Una prueba de concepto de Spectre para una web a prueba de Spectre


Publicado por Stephen Röttger y Artur Janc, ingenieros de seguridad de la información

Hace tres años, Espectro cambió la forma en que pensamos sobre los límites de seguridad en la web. Rápidamente quedó claro que fallas en los procesadores modernos socavó las garantías que los navegadores web podían ofrecer sobre la prevención de fugas de datos entre aplicaciones. Como resultado, los proveedores de navegadores web han estado colaborando continuamente en enfoques destinados a fortalecer la plataforma a escala. Sin embargo, esta clase de ataques sigue siendo una preocupación y requiere que los desarrolladores web implementen mitigaciones a nivel de aplicación.

En esta publicación, compartiremos los resultados de la investigación del equipo de seguridad de Google sobre la explotabilidad de Spectre contra los usuarios web y presentaremos una prueba de concepto (PoC) rápida y versátil escrita en JavaScript que puede filtrar información de la memoria del navegador. Hemos confirmado que esta prueba de concepto, o sus variantes, funcionan en una variedad de sistemas operativos, arquitecturas de procesadores y generaciones de hardware.

Al compartir nuestros hallazgos con la comunidad de seguridad, nuestro objetivo es brindar a los propietarios de aplicaciones web una mejor comprensión del impacto que las vulnerabilidades de Spectre pueden tener en la seguridad de los datos de sus usuarios. Finalmente, esta publicación describe las protecciones disponibles para los autores web y las mejores prácticas para habilitarlas en aplicaciones web, según nuestra experiencia en Google.

Un poco de historia

los Espectro vulnerabilidad, divulgado para el público en enero de 2018, hace uso de una clase de vulnerabilidades de diseño de procesador (CPU) que permiten a un atacante cambiar el flujo de control del programa previsto mientras la CPU ejecuta especulativamente instrucciones posteriores. Por ejemplo, la CPU puede especular que pasa una verificación de longitud, mientras que en la práctica accederá a la memoria fuera de los límites. Si bien el estado de la CPU se revierte una vez que se nota la predicción errónea, este comportamiento deja efectos secundarios observables que pueden filtrar datos a un atacante.

En 2019, el equipo responsable de V8, el motor JavaScript de Chrome, publicó un entrada en el blog y papel blanco concluyendo que tales ataques no se puede mitigar de manera confiable a nivel de software. En cambio, las soluciones sólidas para estos problemas requieren que los límites de seguridad en aplicaciones como los navegadores web estén alineados con primitivas de bajo nivel, por ejemplo aislamiento basado en procesos.

Paralelamente, los proveedores de navegadores y los organismos de normalización desarrollaron mecanismos de seguridad para proteger a los usuarios web de estas clases de ataques. Esto incluyó ambos cambios arquitectónicos que ofrecen protecciones predeterminadas habilitadas en algunas configuraciones de navegador (como Aislamiento del sitio, iframes fuera de proceso, y Bloqueo de lectura de origen cruzado), así como características de seguridad optativas de amplia aplicación que los desarrolladores web pueden implementar en sus aplicaciones: Política de recursos de origen cruzado, Política de apertura de origen cruzado, Política de incrustación de origen cruzado, y otros.

Estos mecanismos, aunque de importancia crucial, no impiden la explotación de Spectre; más bien, protegen los datos confidenciales para que no estén presentes en partes de la memoria desde las que el atacante puede leerlos. Por lo tanto, para evaluar la solidez de estas defensas, es importante desarrollar herramientas de seguridad que ayuden a los ingenieros de seguridad a comprender las implicaciones prácticas de los ataques de ejecución especulativa para sus aplicaciones.

Demostrando Spectre en un navegador web

Hoy, compartimos código de prueba de concepto (PoC) que confirma la practicidad de las vulnerabilidades de Spectre contra los motores JavaScript. Usamos Google Chrome para demostrar nuestro ataque, pero estos problemas no son específicos de Chrome, y esperamos que otros navegadores modernos sean igualmente vulnerables a este vector de explotación. Hemos desarrollado una demostración interactiva del ataque disponible en https://leaky.page/; el código y una redacción más detallada se publican en Github aquí.

(incrustar) https://www.youtube.com/watch?v=V_9cQP60ZGI (/ incrustar)

El sitio web de demostración puede filtrar datos a una velocidad de 1kB / s cuando se ejecuta en Chrome 88 en una CPU Intel Skylake. Tenga en cuenta que es probable que el código requiera modificaciones menores para aplicarlo a otras CPU o versiones del navegador; sin embargo, en nuestras pruebas, el ataque fue exitoso en varios otros procesadores, incluida la CPU ARM de Apple M1, sin cambios importantes.

Mientras experimentamos, también desarrollamos otras PoC con diferentes propiedades. Algunos ejemplos incluyen:

  • Un PoC que puede filtrar 8kB / s de datos a un costo de estabilidad reducida usando performance.now () como un temporizador con precisión de 5μs.

  • Un PoC que filtra datos a 60 B / s utilizando temporizadores con una precisión de 1 ms o peor.

Elegimos lanzar el PoC actual ya que tiene un tiempo de configuración insignificante y funciona en ausencia de temporizadores de alta precisión, como SharedArrayBuffer.

Los principales componentes básicos del PoC son:

  1. Un espectro artilugio: código que activa la ejecución transitoria controlada por el atacante.

  2. A canal lateral: una forma de observar los efectos secundarios de la ejecución transitoria.

1. El gadget

Para el PoC publicado, implementamos un sencillo Variante 1 gadget: se accede especulativamente a una matriz de JavaScript fuera de los límites después de entrenar el predictor de rama para que la comprobación de longitud insertada por el compilador sea correcta. Este dispositivo en particular se puede mitigar a nivel de software; sin embargo, el equipo V8 de Chrome concluido que este no es el caso de otros dispositivos: "Descubrimos que la mitigación efectiva de algunas variantes de Spectre, particularmente la variante 4, es simplemente inviable en el software."

Invitamos a la comunidad de seguridad a ampliar nuestra investigación y desarrollar código que utilice otros dispositivos de Spectre.

2. El canal lateral

Una forma común de filtrar datos secretos a través de la ejecución especulativa es usar un caché canal lateral. Al observar si una determinada ubicación de memoria está presente en la caché o no, podemos inferir si se ha accedido a ella durante la ejecución especulativa. El desafío en JavaScript es encontrar un temporizador de alta resolución que permita distinguir la caché de los accesos a la memoria, ya que los navegadores modernos han reducido la granularidad del temporizador del performance.now () API y deshabilitado SharedArrayBuffers en contextos sin aislamiento de origen cruzado para evitar ataques de tiempo.

Ya en 2018, el equipo V8 compartió su observación que la granularidad reducida del temporizador no es suficiente para mitigar Spectre, ya que los atacantes pueden amplificar arbitrariamente las diferencias de tiempo. La técnica de amplificación presentada se basó en la lectura de datos secretos varias veces, lo que puede, sin embargo, reducir la efectividad del ataque si la filtración de información es probabilística.

En nuestro PoC, desarrollamos una nueva técnica que supera esta limitación. Al abusar del comportamiento de los Árbol-PLRU La estrategia de desalojo de caché que se encuentra comúnmente en las CPU modernas, pudimos amplificar significativamente el tiempo de caché con una sola lectura de datos secretos. Esto nos permitió filtrar datos de manera eficiente incluso con temporizadores de baja precisión. Para obtener detalles técnicos, consulte la demostración en https://leaky.page/plru.html.

Si bien no creemos que este PoC en particular pueda reutilizarse para propósitos nefastos sin modificaciones significativas, sirve como una demostración convincente de los riesgos de Spectre. En particular, esperamos que proporcione una señal clara a los desarrolladores de aplicaciones web de que deben considerar este riesgo en sus evaluaciones de seguridad y tomar medidas activas para proteger sus sitios.

Implementación de defensas web contra Spectre

La naturaleza de bajo nivel de las vulnerabilidades de ejecución especulativa las hace difícil para corregirlo de manera integral, ya que un parche adecuado puede requerir cambios en el firmware o hardware en el dispositivo del usuario. Si bien los desarrolladores de sistemas operativos y navegadores web han implementado importantes protecciones integradas siempre que sea posible (incluyendo Aislamiento del sitio con iframes fuera de proceso y Bloqueo de lectura de origen cruzado en Google Chrome, o Proyecto Fisión en Firefox), el diseño de las API web existentes aún hace posible que los datos fluyan inadvertidamente al proceso de un atacante.

Teniendo esto en cuenta, los desarrolladores web deberían considerar aislar sus sitios de forma más sólida mediante el uso de nuevos mecanismos de seguridad que niegan activamente a los atacantes el acceso a recursos de origen cruzado. Estas protecciones mitigan los ataques de hardware de estilo Spectre y los fugas entre sitios, pero requieren que los desarrolladores evalúen la amenaza que estas vulnerabilidades representan para sus aplicaciones y comprendan cómo implementarlas. Para ayudar en esa evaluación, el equipo de seguridad de la plataforma web de Chrome ha publicado Desarrollo web post-Spectre y Mitigar los ataques de canal lateral con consejos concretos para desarrolladores; Recomendamos encarecidamente seguir su orientación y habilitar las siguientes protecciones:

  • Política de apertura de origen cruzado (COOP) permite a los desarrolladores asegurarse de que la ventana de su aplicación no reciba interacciones inesperadas de otros sitios web, lo que permite que el navegador la aísle en su propio proceso. Esto agrega una protección importante a nivel de proceso, particularmente en navegadores que no habilitan el aislamiento completo del sitio; ver web.dev/coop-coep.

  • Política de incrustación de origen cruzado (COEP) garantiza que todos los recursos autenticados solicitados por la aplicación hayan optado explícitamente por ser cargados. Hoy en día, para garantizar el aislamiento a nivel de proceso para aplicaciones altamente sensibles en Chrome o Firefox, las aplicaciones deben habilitar tanto COEP como COOP; ver web.dev/coop-coep.

Además de habilitar estos mecanismos de aislamiento, asegúrese de que su aplicación también habilite protecciones estándar, como la Opciones de X-Frame y X-Content-Type-Options encabezados y usos Cookies de SameSite. Muchas aplicaciones de Google ya han implementado, o están en proceso de implementar estos mecanismos, proporcionando una defensa contra errores de ejecución especulativos en situaciones en las que las protecciones predeterminadas del navegador son insuficientes.

Es importante tener en cuenta que, si bien todos los mecanismos descritos en este artículo son primitivos de seguridad importantes y poderosos, no garantizan una protección completa contra Spectre; requieren un enfoque de implementación considerado que tenga en cuenta los comportamientos específicos de la aplicación dada. Alentamos a los ingenieros e investigadores de seguridad a utilizar y contribuir a nuestro Spectre prueba de concepto para revisar y mejorar la postura de seguridad de sus sitios.

Consejo: Para ayudarlo a proteger su sitio web de Spectre, el equipo de seguridad de Google ha creado Espectroscopio, un prototipo de extensión de Chrome que escanea su aplicación y encuentra recursos que pueden requerir la habilitación de defensas adicionales. Considere usarlo para ayudarlo con sus implementaciones de funciones de aislamiento web.




Enlace a la noticia original