GoFetch: un nuevo ataque de canal lateral que usa prefetchers dependientes de memoria de datos
(gofetch.fail)- El prefetcher dependiente de memoria de datos (DMP) trata los valores de datos del código criptográfico como si fueran direcciones, lo que puede filtrar claves secretas incluso en implementaciones de tiempo constante (constant-time)
- En las CPU Apple serie M, cuando un valor cargado desde memoria parece un puntero, el DMP intenta desreferenciarlo, lo que debilita la premisa de programación de tiempo constante de separación entre datos y direcciones
- Los investigadores demostraron en Apple M1 la extracción de claves de extremo a extremo en OpenSSL Diffie-Hellman, descifrado RSA en Go, CRYSTALS-Kyber y CRYSTALS-Dilithium, y confirmaron un comportamiento similar del DMP en M2 y M3
- En M3, el bit DIT desactiva eficazmente el DMP, pero esto no aplica a M1 ni M2; el bit de configuración HID descubierto en abril de 2024 es difícil de usar de inmediato porque macOS no tiene soporte en el kernel
- Las mitigaciones incluyen mantener el software actualizado, usar los bits DIT/DOIT en algunas CPU, input blinding y evitar compartir hardware; evaluar la vulnerabilidad requiere criptoanálisis y revisión de código
Lo esencial del ataque GoFetch
- GoFetch es un ataque de canal lateral microarquitectónico que utiliza el prefetcher dependiente de memoria de datos (DMP)
- Permite extraer claves secretas incluso de implementaciones criptográficas escritas en tiempo constante
- Los objetivos demostrados por los investigadores son los siguientes:
- OpenSSL Diffie-Hellman Key Exchange
- Go RSA decryption
- CRYSTALS-Kyber
- CRYSTALS-Dilithium
- El paper y las herramientas están disponibles como Paper y Tools, respectivamente
Cómo el DMP rompe la premisa del tiempo constante
- El DMP de las CPU Apple serie M se activa e intenta desreferenciar cuando los datos cargados desde memoria son un valor que parece un puntero
- La programación de tiempo constante debe separar datos y direcciones para que las bifurcaciones, los bucles, los accesos a memoria y los índices de arreglos no cambien según valores secretos
- Aunque el código de la víctima respete esta regla, el DMP puede crear en su lugar, a nivel de hardware, accesos a memoria dependientes de secretos
- Como resultado, aparece una diferencia de tiempo observable en código que originalmente debería ser de tiempo constante, dejándolo expuesto a ataques de extracción de claves
Procedimiento del ataque
- El atacante construye una entrada elegida para la operación criptográfica de modo que, solo cuando adivina correctamente una parte de la clave secreta, aparezca en el estado intermedio un valor que parece un puntero
- Luego, mediante análisis de temporización de caché, verifica si el DMP realizó la desreferenciación y confirma si la conjetura fue correcta
- Cuando se confirma una conjetura correcta, se usa el mismo método para adivinar el siguiente grupo de bits de la clave
- Con este procedimiento, es posible extraer claves de extremo a extremo en implementaciones de criptografía clásica y poscuántica
Procesadores afectados y resultados observados
- El ataque GoFetch de extremo a extremo se realizó en hardware equipado con procesadores Apple M1
- Las CPU M2 y M3 también muestran patrones de activación del DMP similares y explotables
- Otras variantes de la serie M, como M2 Pro, no fueron probadas, pero como usan la misma microarquitectura que los modelos simples, probablemente tengan un DMP explotable
- La microarquitectura Raptor Lake de Intel de 13.ª generación también tiene DMP
- Sin embargo, sus criterios de activación son más restrictivos, por lo que es robusta frente al ataque GoFetch
Diferencias con Augury
- El DMP de Apple serie M fue descubierto por primera vez por Augury
- Augury consideró que el DMP podía mezclar datos y direcciones bajo ciertas condiciones
- Los investigadores de GoFetch concluyeron que los criterios de activación del DMP descritos por Augury eran demasiado restrictivos
- En el comportamiento real, cualquier valor cargado desde memoria puede convertirse en candidato a desreferenciación, lo que conduce a un ataque de extremo a extremo contra código criptográfico real de tiempo constante
Contexto sobre cachés y prefetchers
- Los procesadores modernos usan cachés para reducir la latencia de los accesos a memoria
- Los datos accedidos previamente permanecen en caché, por lo que accesos posteriores son más rápidos
- Un atacante que se ejecuta en la misma máquina puede observar el estado de la caché compartida e inferir el patrón de accesos de la víctima
- Los prefetchers comunes predicen las direcciones a las que se accederá en el futuro a partir del seguimiento de direcciones de memoria accedidas previamente
- El DMP decide qué datos traer considerando también el contenido de la memoria, para manejar patrones de acceso irregulares como el recorrido de listas enlazadas
- Este comportamiento mezcla datos y direcciones de memoria a nivel de hardware, por lo que puede hacer que toda la pila de cómputo se comporte como si no fuera de tiempo constante (non-constant-time)
Cómo determinar la vulnerabilidad y mitigaciones
- Para determinar si una implementación es vulnerable, hay que saber en qué momento y de qué forma los valores intermedios pueden parecer punteros de manera dependiente de secretos
- Esta evaluación requiere criptoanálisis y revisión de código; es manual, lenta y no descarta otros métodos de ataque
- En algunos procesadores es posible desactivar el DMP
- En abril de 2024, Hector Martin (marcan) descubrió en CPU M1 y M2 el bit de configuración HID
SYS_APL_HID11_EL1[30], que desactiva el DMP- Configurar este chicken bit requiere soporte del kernel
- Actualmente macOS no cuenta con ese soporte
- Hay información relacionada en la publicación de @marcan
- Para los usuarios, se recomienda usar software reciente y actualizarlo regularmente
- Los desarrolladores de bibliotecas criptográficas pueden configurar los bits DIT/DOIT en las CPU que lo permitan
- El input blinding puede ayudar en algunos esquemas criptográficos a evitar valores intermedios controlados por el atacante
- Evitar compartir hardware para que el atacante no pueda medir la activación del DMP puede reforzar aún más la seguridad de los protocolos criptográficos
Divulgación y actualizaciones posteriores
- Los investigadores comunicaron los resultados a Apple el 5 de diciembre de 2023, 107 días antes del lanzamiento público
- En agosto de 2024, GoFetch ganó el Pwnie Award 2024 Best Cryptographic Attack
- En diciembre de 2024, un estudio posterior aplicó ingeniería inversa a la semántica del DMP de Intel y mostró una técnica capaz de filtrar información incluso cuando el DMP desreferencia punteros no válidos
- El paper posterior es Peek-a-Walk: Leaking Secrets via Page Walk Side Channels
- El código está en el repositorio de GitHub de Peek-a-Walk
1 comentarios
Comentarios en Hacker News
En una era en la que existen cosas como los efficiency cores, quizá las arquitecturas modernas también necesiten núcleos criptográficos
Estos núcleos deberían ofrecer explícitamente garantías relacionadas con algoritmos de tiempo constante, y no hacer cosas como prefetching o predicción de saltos
Si fuera algo parecido a Itanium pero limitado a un “procesador criptográfico”, tendría muchas menos funciones, así que en principio el área de silicio del núcleo en sí tampoco sería tan grande
Si te toca implementar código criptográfico, este tipo de problemas debe dar ganas de beber. Incluso en el mejor de los casos ya es una batalla difícil, y aunque implementes todo correctamente, un montón de funciones presentes y futuras del procesador pueden romper tu código en cualquier momento
Pero un coprocesador criptográfico es una solución demasiado disruptiva. Habría que construir una montaña de infraestructura para cambiar a ese núcleo y volver, compartir memoria, etc.
Peor aún, no puedes simplemente mover la multiplicación RSA a ese núcleo y ya. La clave tuvo que haberse parseado en algún lugar, ¿entonces el parser también tendría que correr en el núcleo criptográfico? ¿Y si entra por la red? Si proteges toda la clave pero un canal lateral del CPU filtra el mensaje cifrado, ¿está bien? ¿Se considera aceptable porque no es la clave?
La razón por la que este tipo de ataques no se ve tanto en código no criptográfico es que encontrar un objetivo depende demasiado de cada aplicación, mientras que en las bibliotecas criptográficas todos estamos de acuerdo en que filtrar claves es malo
Al final, los diseñadores de procesadores no deberían romper nuestras suposiciones y, al menos, deberían hablar con nosotros antes de hacerlo
La unidad de abstracción probablemente terminaría siendo el hilo
https://support.apple.com/guide/security/secure-enclave-sec5...
Pero las arquitecturas de nube optimizadas por costos se volcaron al hardware de consumo y se comieron el mercado de CPU, así que ahora incluso en aplicaciones a gran escala la única opción realista son CPUs de consumo
También podría ser buena idea agregar algunas instrucciones de primitivas criptográficas para habilitar nuevos algoritmos
Según el artículo, “OpenSSL considera que los ataques locales por canal lateral quedan fuera de su modelo de amenazas, y el equipo de Go Crypto ve baja la gravedad de este ataque”
La conclusión final de este tipo de ataques por canal lateral sería un CPU sin ninguna optimización, en el que todas las instrucciones se ejecuten en la misma cantidad de ciclos en todas las situaciones
Pero eso nunca va a pasar. Nadie quiere un CPU lento
Si no puede explotarse de forma remota, no me parece algo por lo que preocuparse. Claro, la virtualización en nubes multi-tenant no cuenta
Sin ejecución especulativa, sin prefetching, un núcleo como el pipeline de 5 etapas que enseñan en Computación 101
Sí hay algunos proveedores de nube que alquilan tiempo de cómputo en Mac Mini montados en rack, pero no son muchos, y aun así suelen ser para cargas de trabajo o builds muy específicas
Para quienes pagan mucho dinero por esos servicios puede ser un problema, pero la enorme mayoría de los dispositivos con Apple Silicon jamás van a alojar servicios en la nube
Si aíslas el código en un núcleo específico, bajo la suposición de que todo funciona como se espera, el exploit no puede comprometer a otros tenants
Sobre “¿se puede desactivar el DMP?”, dice que “sí, pero solo en algunos procesadores. En CPUs M3, configurar el bit DIT desactiva efectivamente el DMP, pero en M1 y M2 no”
Seguro que en alguna parte hay un chicken bit para apagar esto, ¿no?
¿Se puede hacer desde Swift, o hace falta ensamblador?
Leyéndolo, parece que bibliotecas como libsodium podrían simplemente configurar un bit de desactivación antes de operaciones criptográficas sensibles en M3 o superior
También parece que hace falta conocer de antemano ciertos aspectos de la clave
Muy interesante, pero no se ve especialmente práctico
Me recordó al ataque Augury de 2022. Ese también explotaba el prefetching DMP en CPUs Apple Silicon
[1]: https://www.prefetchers.info
¿Por qué Apple tiene tantos backdoo… digo, bugs puramente de hardware?
Para responder a esa conspiranoia absurda sobre backdoors: la gente quiere CPUs rápidos, así que los procesadores tienen caché y diferencias de tiempo. No puedes tener tiempo constante y alto rendimiento al mismo tiempo, y Apple no es la única empresa que usa prefetching
Aquí hay documentación de Apple sobre cómo habilitar operaciones de tiempo constante para criptografía. Casi parece que estuviera diseñado intencionalmente en el hardware. Qué raro: https://developer.apple.com/documentation/xcode/writing-arm6...
Si vas a escribir rutinas criptográficas, deberías usar la biblioteca criptográfica de la plataforma o seguir la documentación
https://developer.apple.com/documentation/xcode/writing-arm6...
Ahora también tiene sentido hacer análisis de malware y usar escáneres de virus en Mac y iPad
El atacante tiene que estar ejecutándose en el mismo hardware