GPUThor: un ataque Rowhammer burla la protección ECC de las GPU Nvidia

Investigadores de la Universidad de Toronto revelaron a finales de agosto una nueva técnica de ataque llamada GPUThor, capaz de burlar la protección ECC (código de corrección de errores) integrada en las GPU de Nvidia. El método, basado en el principio Rowhammer, se validó en GPU de estación de trabajo con arquitectura Ampere y memoria GDDR6 —las RTX A4000, A4500, A5000 y A6000—, modelos muy utilizados en infraestructuras de IA y de nube. El equipo notificó el fallo a Nvidia el 29 de abril, y la empresa publicó recomendaciones de mitigación el 25 de agosto, tras unos cuatro meses de divulgación coordinada.

Por qué la ECC es indispensable en una GPU de IA

Un chip de memoria sometido a carga sostenida puede sufrir de forma aleatoria una «inversión de bit»: un bit almacenado como 0 cambia accidentalmente a 1, o al revés, por efecto de rayos cósmicos, interferencias eléctricas o defectos de fabricación. En el uso cotidiano, una inversión aislada suele pasar inadvertida. Pero en el entrenamiento o la inferencia de un modelo de IA puede corromper directamente pesos, gradientes o valores de activación, desviando silenciosamente un entrenamiento o produciendo, en inferencia, una respuesta errónea pero verosímil, sin ninguna alerta. Para eso existe la ECC: al guardar un código de verificación adicional junto a cada bloque de memoria, el sistema corrige automáticamente los errores de un bit y detecta los de dos bits, un esquema conocido como SECDED. Es esa garantía la que permite a los proveedores de nube compartir con confianza una misma GPU física entre varios clientes.

Cómo GPUThor rompe la protección ECC

GPUThor golpea la memoria con un patrón deliberadamente no uniforme, aprovechando además dos comportamientos de la GPU que Nvidia nunca había documentado: cómo el chip agrupa (coalesce) las peticiones repetidas de acceso a memoria, y con qué frecuencia se activa realmente el mecanismo Target Row Refresh (TRR) de la memoria GDDR6. Al mantenerse justo por debajo del umbral de detección del TRR, GPUThor puede seguir «martilleando» sin parar una fila de memoria objetivo, provocando inversiones de bit en las filas vecinas.

• En las GPU probadas sin ECC activada, GPUThor provocó entre 72.000 y 377.000 inversiones de bit por gigabyte de memoria, hasta 23.597 veces más que el ataque anterior del equipo, GPUHammer.
• Incluso con la ECC activada, GPUThor generó 387 errores de dos bits (que la ECC detecta pero no puede corregir) y dos errores de tres bits, que superan la capacidad de corrección de la ECC y provocaron corrupción de datos.
• Encontrar una inversión de bit explotable ahora toma en promedio unos 1,1 minutos, frente a las 21,9 horas que requería GPUHammer.
• Un ataque sostenido sobre una RTX A6000 con ECC activada puede forzar a la GPU a reiniciarse cada dos horas, interrumpiendo todas las tareas en curso; si se repite, la tarjeta puede llegar a marcarse a sí misma como necesitada de reemplazo.

Más allá de la denegación de servicio, los investigadores demostraron un escenario más grave: al corromper las tablas de páginas de la GPU, un programa CUDA sin privilegios especiales puede obtener acceso arbitrario a la memoria y abrir un shell root en la máquina anfitriona, convirtiendo una tarea normal de cómputo en GPU en el control total del servidor. Las GPU de centro de datos de la generación Ampere, como la A100, resisten mejor la denegación de servicio pero siguen siendo vulnerables a la escalada de privilegios; incluso las GPU Blackwell con protección RAS Repair solo consiguen alargar el ataque, no impedirlo. Los investigadores advierten de que las futuras GPU con GDDR7 o HBM3e, con ECC integrada en la propia memoria, podrían seguir siendo vulnerables ante inversiones de múltiples bits.

Quién está realmente expuesto

GPUThor apunta a los clústeres de GPU de centros de datos que sostienen el entrenamiento y la inferencia de IA, en particular a las instancias de GPU en la nube multiinquilino —el modelo por defecto de la mayoría de las ofertas de GPU en la nube pública, donde varios clientes comparten una misma tarjeta física—. Un atacante que alquile solo una pequeña franja de cómputo podría interrumpir, o incluso corromper, el entrenamiento o la inferencia de otro cliente alojado en el mismo hardware, un riesgo invisible desde la capa de aplicación. Las recomendaciones de Nvidia se centran en el aislamiento y la vigilancia: activar SYS-ECC y el aislamiento IOMMU/DMA, monitorizar de forma continua la telemetría de errores de la GPU y restringir el uso compartido de cargas CUDA no confiables en el mismo hardware.

Qué cambia para las empresas de habla hispana

Muchas empresas de habla hispana entrenan o ejecutan modelos de IA alquilando instancias de GPU a proveedores como AWS, Microsoft Azure o Google Cloud, además de operadores regionales más pequeños. GPUThor recuerda que la GPU física detrás de esa llamada de API rara vez es hardware dedicado: casi siempre se comparte con otros clientes. Antes de dar por hecho que una instancia de GPU en la nube es un entorno aislado y de confianza, los equipos de seguridad e infraestructura deberían confirmar con su proveedor si SYS-ECC y el aislamiento IOMMU/DMA recomendados por Nvidia están realmente activados, pedir visibilidad sobre la telemetría de errores de la GPU e incorporar el aislamiento multiinquilino a las revisiones de seguridad de proveedores, no como una casilla más en una ficha técnica, sino como una pregunta real sobre cómo se protege una tarjeta compartida.