Ataque Downfall
(downfall.page)- Vulnerabilidad CVE-2022-40982 en procesadores Intel ampliamente usados en computadoras personales y en la nube, que permite robar datos de otros usuarios que comparten la misma computadora
- El punto central de la vulnerabilidad es que, durante la optimización de memoria, la instrucción Gather expone el contenido del archivo interno de registros vectoriales durante la ejecución especulativa
- El ataque se implementa con las técnicas GDS·GVI; en las demos se muestra la filtración a través de límites de aislamiento de claves AES, datos del Linux Kernel e incluso monitoreo de caracteres imprimibles
- El alcance va desde Intel Core de 6.ª generación Skylake hasta 11.ª generación Tiger Lake, y los usuarios de la nube pueden verse afectados aunque no posean directamente dispositivos Intel
- La actualización de microcódigo de Intel bloquea los resultados transitorios de Gather, pero algunas cargas de trabajo pueden sufrir hasta 50% de sobrecarga tras aplicar la mitigación
La vulnerabilidad a la que apunta Downfall
- Downfall apunta a una debilidad crítica en procesadores modernos usados en computadoras personales y en la nube
- Esta vulnerabilidad se identifica como CVE-2022-40982
- Permite acceder y robar datos de otros usuarios que comparten la misma computadora
- Una app maliciosa descargada desde una tienda de aplicaciones podría robar información sensible como contraseñas, claves de cifrado, datos bancarios, correos personales y mensajes
- En la nube, un cliente malicioso podría robar datos y credenciales de otros clientes que comparten la misma computadora en la nube
Causa técnica de la vulnerabilidad
- Una función de optimización de memoria de los procesadores Intel expone involuntariamente registros internos de hardware al software
- Software no confiable puede acceder a datos de otros programas a los que originalmente no debería tener acceso
- La instrucción Gather, diseñada para leer más rápido datos dispersos en memoria, filtra el contenido del archivo interno de registros vectoriales durante la ejecución especulativa
- Para explotarlo se usan las técnicas Gather Data Sampling(GDS) y Gather Value Injection(GVI)
- Los detalles técnicos están resumidos en el paper de Downfall
Casos de filtración confirmados en demos
- Las demos de Downfall muestran que datos sensibles pueden filtrarse a través de distintos límites de aislamiento
Sistemas afectados y condiciones de ataque
- Los dispositivos afectados son equipos de cómputo basados en procesadores Intel Core desde la 6.ª generación Skylake hasta la 11.ª generación Tiger Lake
- Intel publicará una lista más completa de procesadores afectados en su lista de procesadores afectados
- Aunque no tengan un dispositivo físico basado en Intel, los usuarios de la nube pueden verse afectados
- La participación de Intel en el mercado de servidores supera el 70%
- Un atacante puede apuntar a credenciales de alto valor, como contraseñas y claves de cifrado
- El robo de credenciales puede ir más allá de una violación de confidencialidad y derivar en otros ataques que afecten la disponibilidad e integridad de la computadora
- GDS es relativamente fácil de implementar como ataque real
- Desarrollar un ataque end-to-end para robar claves de cifrado en OpenSSL tomó 2 semanas
- Basta con que el atacante y la víctima compartan el mismo núcleo físico del procesador
- En computadoras modernas que implementan multitarea con desalojo y multithreading simultáneo, este tipo de uso compartido ocurre con frecuencia
Límites de aislamiento, SGX e impacto en navegadores
- Downfall también afecta límites de aislamiento comunes
- Máquinas virtuales
- Procesos
- Aislamiento usuario-kernel
- Intel SGX también se ve afectado
- Intel SGX es una función de seguridad de hardware en CPU Intel para proteger datos de usuarios frente a software malicioso
- La explotación remota a través de navegadores web es teóricamente posible
- Para demostrar un ataque exitoso en navegadores reales, se requiere más investigación y trabajo de ingeniería
Periodo de exposición y dificultad de detección
- Los usuarios estuvieron expuestos a esta vulnerabilidad durante al menos 9 años
- Los procesadores afectados existen desde 2014
- Los ataques Downfall son difíciles de detectar
- Su forma de ejecución parece, en su mayor parte, la de una aplicación normal
- En teoría, podría construirse un sistema que use contadores de rendimiento de hardware para detectar comportamientos anómalos, como un exceso de fallos de caché
- El software antivirus comercial común no puede detectar este ataque
Mitigaciones y sobrecarga de rendimiento
- Intel distribuyó una actualización de microcódigo
- Esta actualización bloquea los resultados transitorios de la instrucción Gather
- Impide que el código del atacante observe datos especulativos provenientes de Gather
- La sobrecarga de la mitigación depende de si Gather está en la ruta crítica de ejecución del programa
- Según Intel, algunas cargas de trabajo pueden sufrir hasta 50% de sobrecarga
- No es seguro desactivar la mitigación solo porque una carga de trabajo no use Gather
- Las CPU modernas usan registros vectoriales para optimizar operaciones comunes, como copias de memoria y cambios de contenido de registros
- Durante ese proceso, los datos pueden filtrarse a código no confiable que explote Gather
Cronograma de divulgación y código de reproducción
- Esta vulnerabilidad estuvo bajo embargo durante casi 1 año
- Fue reportada a Intel el 24 de agosto de 2022
- Downfall se presentó el 9 de agosto de 2023 en BlackHat USA y el 11 de agosto de 2023 en el USENIX Security Symposium
- El código de reproducción está disponible en GitHub POC
Puntos de atención para otros diseñadores de procesadores
- Otros procesadores también tienen memoria SRAM compartida dentro del núcleo, como archivos de registros de hardware y fill buffers
- Los fabricantes deben diseñar con más cuidado las unidades de memoria compartida para evitar que los datos se filtren entre distintos dominios de seguridad
- Deben invertir más en verificación y pruebas de seguridad
Nombre y vulnerabilidades relacionadas
- El nombre Downfall se debe a que derriba los límites básicos de seguridad de la mayoría de las computadoras
- Downfall puede verse como sucesor de vulnerabilidades anteriores de filtración de datos en CPU, como Meltdown y Fallout
- En esta línea, Downfall vuelve a eludir mitigaciones anteriores
Recomendaciones de proveedores y documentación técnica
- Avisos de seguridad:
- MITRE: CVE-2022-40982
- Intel: INTEL-SA-00828
- AWS: AWS-2023-007
- GCP: GCP-2023-024
- Debian: CVE-2022-40982
- Ubuntu: CVE-2022-40982
- Red Hat: CVE-2022-40982
- VMware: respuesta a Gather Data Sampling
- Documentación técnica de Intel:
1 comentarios
Opiniones de Hacker News
Incluso después del ataque inicial Spectre, se siente raro que investigadores externos sigan encontrando ataques similares y que los fabricantes de chips los parcheen después.
En principio, los fabricantes de chips son los expertos en ejecución especulativa, conocen con precisión cómo funcionan los chips y tienen suites de validación, simuladores e incluso especificaciones internas legibles por máquina, así que deberían estar en la mejor posición para descubrirlos.
Los investigadores externos tienen que explorar una caja negra y hacer ingeniería inversa con materiales mucho más pobres, como patentes, y aun así, años después, individuos o grupos externos siguen encontrando estas vulnerabilidades.
Antes de Spectre quizá no se había considerado este vector de ataque, pero una vez revelado el mecanismo general, ¿no deberían los fabricantes de chips haber reunido a sus personas más inteligentes y dicho “revisen todo a fondo y encuentren otros ataques tipo Spectre”?
Tal vez ya lo saben todo, pero lo mantienen enterrado esperando que no se haga público para evitar quedar mal y sufrir pérdidas de rendimiento.
Si algo lo usan miles de millones de personas, creo que se le van a encontrar más problemas, defectos y exploits que quienes lo crearon. El simple hecho de que esos problemas existan no respalda ni refuta conclusiones adicionales sobre el motivo.
Los investigadores de seguridad tienen incentivos para encontrar algo y construir reputación. A menudo presentan algo como una vulnerabilidad de seguridad capaz de sacudir al mundo, aunque para atacantes reales no tenga mucho sentido.
¿Alguna vez se ha descubierto un ataque de ejecución especulativa en entornos reales? Tal vez no. Si es así, los proveedores de chips tienen pocos motivos para gastar enormes sumas de dinero en esto.
Los clientes reales no sufren daños, salvo cuando investigadores externos obligan a tomar medidas y eso lleva a publicar nuevo microcódigo que reduce el rendimiento.
También vale la pena notar que las mitigaciones para estos ataques siempre vienen con un interruptor para desactivarlas. No es una forma común en correcciones de seguridad, y en muchos casos se debe a que estos ataques no importan demasiado.
El software que corre en el mismo núcleo físico o en la misma CPU física tiene el mismo nivel de confianza, o está aislado en un sandbox lo bastante fuerte como para no poder realizar el ataque.
Intel, sin duda, hace sus chips “lo más ingeniosos posible” y, por lo tanto, por definición no pueden depurarse por completo.
También es importante señalar que estos no son bugs. El diseño funciona como se pretendía. Se entendía que el rendimiento de la CPU variaba según el código ejecutado previamente, y se aceptó porque el costo de las alternativas en términos de energía, rendimiento y área se consideraba demasiado alto. Eso es ingeniería: sopesar alternativas y elegir.
En este caso, al volverse las CPU lo suficientemente rápidas, una pequeña fracción de bit por iteración se convirtió en ancho de banda atacable, pero alguien tenía que demostrarlo para que la industria lo entendiera. Eso cambió el criterio de ingeniería.
El enlace al paper de Intel está caído, y el enlace correcto parece ser este: https://www.intel.com/content/www/us/en/developer/articles/t...
Como advertencia general, ¿todavía hay muchos proveedores cloud que ejecuten cargas de trabajo de distintos usuarios en el mismo núcleo físico? Pensé que la mayoría había cambiado sus schedulers hace años para evitar filtraciones entre dominios a través de hyperthreads.
La afirmación de que afecta a todos los usuarios de Internet parece una exageración excesiva. Tampoco se ve ningún exploit basado en navegador y, aunque existiera, solo afectaría a un número ínfimo de usuarios atacados específicamente. Han pasado varios años desde Spectre, y me pregunto si alguna vez se han encontrado ataques de ejecución especulativa en entornos reales.
Lo más interesante es que estos bugs de ejecución especulativa siguen pareciendo parcheables mediante microcódigo. Cuando aparecieron por primera vez existía el temor de que quizá hubiera que desechar y reemplazar chips físicos en masa, pero ¿alguna vez fue realmente necesario?
Hasta donde sé, todos los bugs pudieron mitigarse con una combinación de cambios de software y microcódigo, pagando en algunos casos cierto costo de rendimiento. Ningún bug requirió silicio nuevo. La excepción sería algo como las primeras versiones de AMD SEV, que efectivamente fueron vulneradas de forma imposible de parchear.
Claro, también hay opciones compartidas como la serie T de AWS, y seguramente otros clouds tienen algo similar, pero supongo que podrían insertar “flushes” adicionales entre usuarios para impedir filtraciones entre tenants.
Naturalmente, las filtraciones entre procesos dentro de un mismo tenant son un problema tanto en cloud como on-premises y, al final, hay que decidir cuánto confías en que los procesos de tu propia máquina no se vuelvan maliciosos.
Ejecutar código de distintos dominios de seguridad en el mismo núcleo físico de procesador parece imposible de hacer bien, y creo que ya deberíamos dejar de hacerlo.
En la práctica, los casos comunes son básicamente dos: VM y JavaScript.
Con las VM hay que darse por vencidos. Hay que dedicar determinados núcleos a determinadas VM, o al menos a determinados clientes.
JavaScript es un poco más difícil.
En cualquier caso, no deberíamos sacrificar rendimiento en el caso general.
La IOPU se encargaría de dirigir el resto del hardware del sistema y no necesitaría tener un rendimiento muy alto.
La SPU estaría optimizada para código escalar y código con muchas ramas que deba ejecutarse rápido.
La SPU solo necesitaría una seguridad mínima, como impedir lecturas de memoria arbitraria al traer datos desde la RAM. Como ejecutaría un solo programa a la vez, la ejecución especulativa no sería un problema.
En mi sistema hay pocos programas que necesiten mucha capacidad de procesamiento y, aun cuando la necesitan, es de forma intermitente, así que no creo que haya muchos cambios de tarea en la SPU.
Estos ataques a CPU muestran que un sistema seguro de tiempo compartido donde los usuarios ejecutan código máquina arbitrario ya no es realista.
El tiempo compartido seguirá existiendo cuando los usuarios confíen entre sí, como cuando personas de un mismo proyecto comparten una máquina de builds.
La idea de que se puede impedir que dos programas ejecutándose en una computadora se espíen mutuamente está a ese mismo nivel.
Aviso de seguridad de Intel: https://www.intel.com/content/www/us/en/developer/articles/t...
Merge en el kernel de Linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Que solo afecte hasta la 11.ª generación no me hace pensar que esta vulnerabilidad se haya informado a Intel lo suficientemente temprano como para corregirla en la 12.ª generación. Entonces me pregunto si se resolvió por casualidad al arreglar otra cosa
Al ver el paper, dice: “Intel afirmó que las CPU más recientes, como Alder Lake, Raptor Lake y Sapphire Rapids, no están afectadas. Sin embargo, esto parece ser más un efecto secundario de una arquitectura muy modificada que una consideración de seguridad”
Al final, se corrigió de forma aleatoria o, al menos, este exploit específico dejó de funcionar
Según las FAQ, los usuarios estuvieron expuestos a esta vulnerabilidad durante al menos 9 años, porque los procesadores afectados existen desde 2014
Es sorprendente que una vulnerabilidad así pase desapercibida durante años y luego a alguien le tome solo 2 semanas programar un exploit
Ver también el artículo de LWN: https://lwn.net/Articles/940783/
En Linux, para las CPU que no tienen microcódigo actualizado, AVX se deshabilita por completo como mitigación de este problema. A mi juicio es bastante duro y creo que se va a notar bastante. Ahora me dieron ganas de averiguar si puedo recibir el microcódigo actualizado
gather_data_sampling=force. El valor predeterminado es dejar AVX como está y marcar el sistema como vulnerableViendo https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...:
si se especifica
gather_data_sampling=force, se usa la mitigación de microcódigo cuando es posible, y en los sistemas afectados cuyo microcódigo no fue actualizado para incluir esa mitigación, se deshabilita AVXComo referencia, trabajo en Linux en Intel. Es muy posible que yo haya escrito o retocado la documentación y los changelogs que confunden a la gente
[ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12Estoy usando Haswell. ¿Hay alguna lista de qué CPU reciben microcódigo actualizado? Qué lástima
También vale la pena señalar que GCP parcheó este problema: https://cloud.google.com/support/bulletins#gcp-2023-024
Los datos y las instancias de los clientes de AWS no se ven afectados por este problema, y los clientes no tienen que tomar ninguna medida
AWS diseñó e implementó infraestructura con protección contra esta clase de problemas. Las instancias de Amazon EC2, incluidos Lambda, Fargate y otros servicios de cómputo y contenedores administrados por AWS, protegen los datos de los clientes frente a GDS mediante microcódigo y mitigaciones basadas en software
El golpe al rendimiento es enorme. Se afirma que llega hasta el 50%, y que el 70% de los procesadores Intel recientes están afectados
https://access.redhat.com/solutions/7027704
El impacto en el rendimiento se limita a aplicaciones que usan la instrucción gather y la instrucción CLWB provistas por Intel Advanced Vector Extensions (AVX2 y AVX-512). El impacto real en el rendimiento depende de cuánto usen esas instrucciones las aplicaciones
Si, tras un análisis de riesgo exhaustivo, el usuario decide desactivar la mitigación —por ejemplo, si el sistema no es multi-tenant y no ejecuta código no confiable—, puede deshabilitarla
Después de aplicar las actualizaciones de microcódigo y del kernel, se puede desactivar la mitigación agregando
gather_data_samping=offa la línea de comandos del kernel. O bien, para desactivar todas las mitigaciones de ejecución especulativa de CPU, incluida GDS, se puede usarmitigations=offSiempre desconfío de las afirmaciones con “hasta”
La NES traía un chipset con un 6502 completo integrado, y por lo que cuesta una pizza hoy puedes comprar un chip Rockchip ARM con núcleos mixtos en el die. Tal vez los fabricantes de chips no tengan que resolver todos los casos extremos para siempre, y puedan devolvernos a quienes devoramos chips este tipo de mitigación de ataques de canal lateral
En lugar de que la opción sea activar o desactivar SMT por completo, ¿qué tal si mandamos el código no confiable a los “núcleos feos” y hacemos que el cliente “demuestre” que se puede subir a núcleos con SMT?
Nadie quiere arruinar un chip que ejecuta tareas de nómina ultracríticas donde no se puede poner otra cosa en la placa. Pero estaría bien que te obliguen a etiquetar lo que puede ejecutarse de forma segura en SMT y, si no, que quede atado a un núcleo más seguro
Un pasante que no tiene ni idea de qué es esto podría buscarlo, aprender cuál es realmente este vector de ataque y armar un plan de defensa
¿Soy yo el raro?
Núcleos de rendimiento × núcleos de eficiencia es viable
Pero nadie querría ser quien proponga núcleos confiables × núcleos no confiables “feos”. Por muchas ventajas que tenga, quedaría enterrado bajo el discurso de que “genera inseguridad”. Así es la vida