DDRop expone vulnerabilidad en memorias cifradas de Intel y AMD con interposer DDR5

Investigadores de KU Leuven, ETH Zurich, Durham University y Google han revelado un ataque de hardware, bautizado DDRop, que puede invalidar la protección de memoria usada por las tecnologías de “confidential computing” en servidores con procesadores Intel y AMD. En laboratorio, los autores demuestran que un pequeño interposer —una placa de circuito que se inserta entre la CPU y un módulo de memoria DDR5— puede descartar escrituras en la memoria de forma silenciosa, de modo que la CPU sigue leyendo datos cifrados antiguos como si fueran los más recientes. Según el equipo, el diseño del interposer y el firmware cuestan menos de 200 dólares en piezas y puede instalarse en pocos minutos.

Hechos confirmados: los investigadores han publicado (según su divulgación coordinada) pruebas de concepto que funcionan sobre DDR5 y muestran impacto en Intel TDX (en su modalidad por defecto, llamada “logical integrity”) y en AMD SEV‑SNP; el ataque actúa suprimiendo comandos de escritura entre la CPU y la DRAM, sin romper el cifrado ni activar las comprobaciones existentes; los autores están liberando diseños, firmware y código en GitHub y presentarán el trabajo en la conferencia ACM CCS 2026. También está confirmado que la técnica requiere (1) control del software de la máquina atacada y (2) acceso físico breve para colocar el interposer; los investigadores dicen no tener evidencia de uso en el mundo real fuera del laboratorio.

Cómo funciona técnicamente: las arquitecturas de memoria cifrada que usan los enclaves o dominios confiables en nube protegen la confidencialidad de la memoria pero, para escalar a grandes cantidades de RAM, renuncian a una garantía llamada freshness (actualidad de los contenidos). El cifrador y sus metadatos comprueban integridad criptográfica según claves, pero no verifican que el valor leído sea la última escritura efectuado por la CPU; por eso una antigua copia válida sigue descifrando correctamente. El interposer diseñado por los investigadores opera como un conmutador de alta velocidad en el bus DDR5: para descartar una escritura, induce un fallo lógico en la señal de comando y luego bloquea la línea de retorno que la memoria usaría para reportar dicho fallo, provocando que el módulo DRAM ignore la orden sin que la CPU lo detecte. El resultado es que una supuesta actualización no llega a la DRAM y lecturas posteriores devuelven el contenido anterior.

Qué permite esto en la práctica: en Intel TDX, el equipo transforma esa falta de escritura en un control efectivo del dominio protegido. Al evitar que el firmware escriba entradas nulas en una nueva tabla de páginas, el atacante hace que la tabla conserve datos previos controlados por él; con esa condición, una máquina virtual atacante puede mapear direcciones físicas de forma arbitraria y acceder o modificar memoria protegida de otra VM, leer su contenido privado y hasta cambiar el “launch measurement” que se usa para atestación remota. En su experimento los investigadores también consiguieron activar el modo debug de una VM víctima y copiar su memoria en claro, reescribiendo después los valores para no dejar traza. En AMD SEV‑SNP el impacto mostrado fue más limitado: los ataques se centraron en operaciones de relocación de páginas, permitiendo copiar una página víctima en otra; las técnicas de alterar atestaciones o activar debug son específicas de Intel según el informe.

Aspectos confirmados vs inciertos: es verificado que DDRop funciona en laboratorio sobre equipos DDR5 y que explota la ausencia de freshness en las soluciones escalables de cifrado de memoria; también está confirmado que la modalidad opcional de Intel conocida como “cryptographic integrity” bloquea algunas variantes del ataque (las que afectan a páginas que pertenecen a otra VM), aunque los investigadores no pudieron probar esa modalidad porque su sistema de pruebas no la soportaba. Queda incierto si la modalidad criptográfica detendría todas las variantes razonables (los autores señalan que la falsificación de una atestación propia podría seguir siendo posible porque ocurre bajo la clave del atacante) y si propuestas de diseño futuras como “cache-line versioning” impedirían DDRop: los investigadores dicen que no está claro.

A quién afecta: principalmente cargas en datacenters que utilizan Intel TDX, Intel scalable SGX y AMD SEV‑SNP ofrecidos por grandes nubes (por ejemplo, servicios en AWS, Azure o Google Cloud que anuncian tecnologías de confidential computing). El ataque no está dirigido a PCs domésticos o móviles y no afecta a chips donde la memoria está encerrada físicamente dentro del paquete (por ejemplo GPUs con memoria on‑package), ni a la antigua Client SGX que sí tiene un árbol de integridad que previene datos obsoletos. También puede no aplicarse a otras arquitecturas (los autores no probaron Arm CCA y lo consideran potencialmente afectable).

Consecuencias reales y riesgos: DDRop no demuestra que proveedores de nube hayan sido quebrantados, pero establece que un atacante con acceso administrativo al software del servidor y un breve acceso físico (un operario malicioso en el datacenter, manipulación en la cadena de suministro o hardware intervenido) podría violar las garantías de confidencialidad e integridad de enclaves. El impacto varía con el modo de seguridad activado en cada CPU: en modo lógico de TDX se muestran ataques críticos; en modo criptográfico el riesgo se reduce pero no desaparece por completo.

Qué deberían hacer las partes implicadas y los usuarios: en primer lugar, los operadores de nube deben revisar controles físicos y de cadena de suministro, reforzar políticas de acceso a racks y DIMMs, monitorizar manipulación física y añadir inspecciones de hardware durante mantenimiento. Técnicamente, deberían habilitar todas las opciones de integridad criptográfica disponibles en sus plataformas y plantear soporte para mecanismos futuros que aporten freshness en el bus de memoria. También conviene implementar detección de interposer en el proceso de arranque del servidor y validar que escrituras críticas se han aplicado (siempre que sea viable).

Para clientes de nube y desarrolladores: no asuman que la confianza del enclave es absoluta frente a ataques físicos. Pregunten a su proveedor si la modalidad de integridad criptográfica está habilitada en los servicios que contratan y si hay medidas de protección física y de cadena de suministro. Además, refuercen la seguridad por capas: cifrado a nivel de aplicación, rotación de claves, minimizar datos sensibles en memoria persistente, aislamiento de workloads críticos y atestación remota cruzada con políticas que detecten discrepancias en mediciones de lanzamiento.

Medidas prácticas inmediatas para administradores y responsables: exigir a la nube la habilitación del modo criptográfico cuando esté disponible, auditar los procesos de mantenimiento físico, limitar privilegios que permitan instalar software con acceso de bajo nivel, y aplicar pruebas de integridad y comprobaciones de writes en componentes de memoria críticos. Los fabricantes de chips (Intel/AMD) han sido informados; históricamente ambos han considerado ataques físicos por interposer fuera del modelo de amenaza estándar, por lo que la mitigación completa probablemente requerirá cambios de hardware en generaciones futuras.

Información útil adicional y fuentes de contexto: la conferencia donde se presentará el trabajo (ACM CCS) es el foro principal para seguridad informática (https://www.sigsac.org/ccs/) y las tecnologías de confidential computing están coordinadas por consorcios del sector (https://confidentialcomputing.io/). Para referencias oficiales sobre la familia de tecnologías afectadas puede consultarse la documentación de AMD sobre SEV (https://www.amd.com/en/technologies/sev), y las notas públicas de los fabricantes cuando publiquen sus boletines en la fecha de divulgación.

Conclusión: DDRop muestra una vulnerabilidad de modelo —no un fallo de implementación— en las actuales soluciones de memoria cifrada a gran escala: la falta de freshness en el bus facilita que un interposer barato y temporal convierta privilegios locales y acceso físico en acceso total a enclaves. Mientras que las mitigaciones reales implicarán diseño de hardware nuevo, operadores y clientes pueden y deben ajustar configuración, controles físicos y prácticas de desarrollo para reducir la exposición.