Nueva vulnerabilidad en Apple M-series que permite extraer claves secretas y no puede parchearse

Artículo original ↗ Discusión en Hacker News ↗

Naturaleza de la vulnerabilidad

  • Ataque de canal lateral, apodado GoFetch, contra el prefetcher dependiente de datos de la memoria (DMP) de Apple M-series.
  • Rompe los supuestos de la criptografía de tiempo constante al pretraer especulativamente datos que “parecen” punteros.
  • Permite extraer claves de implementaciones criptográficas comunes (OpenSSL DH, Go RSA, Kyber, Dilithium) cuando el atacante puede introducir entradas elegidas y monitorizar los tiempos de caché.
  • Funciona en M1 y M2; el bit DIT de M3 puede desactivar el comportamiento problemático cuando las bibliotecas lo adoptan.
  • Se informa que las claves del Secure Enclave no se ven afectadas; el ataque apunta a criptografía en espacio de usuario/espacio kernel, no a claves almacenadas en el enclave.

Explotabilidad práctica y modelos de amenaza

  • Requiere: código atacante sin privilegios en la misma máquina y la capacidad de desencadenar repetidas operaciones de clave privada durante mucho tiempo.
  • La discusión enfatiza procesos co-localizados; los ataques remotos solo por red se consideran imprácticos debido a las minúsculas diferencias de tiempo y al ruido, aunque algunos citan trabajos previos sobre temporización remota en general.
  • Se debatieron posibles vectores: JavaScript malicioso en navegadores, servidores compartidos, gestores de contraseñas, claves de sesión TLS, certificados de cliente. Los escenarios end-to-end realistas siguen sin estar claros.

Impacto en usuarios promedio

  • Un lado: “ningún problema real” para la mayoría; el riesgo está muy superado por la ingeniería social, la reutilización de contraseñas y el software sin parchear.
  • El otro lado: desestimar esto repite las actitudes iniciales ante Spectre/Meltdown; también allí acabaron apareciendo pruebas de concepto en JavaScript.

Centralización de identidad, pagos y apps

  • Crítica fuerte a los teléfonos como puntos únicos de fallo para identidad, pagos y autenticación de apps.
  • Preferencia por tokens físicamente separados (dispositivos hardware bancarios, smartcards) con responsabilidades respaldadas legalmente y “rituales” distintos para acciones de alto valor.
  • Contraargumento: los ecosistemas centrados en móviles con biometría (Apple Pay, passkeys) han mejorado mucho la seguridad y la comodidad, y son ampliamente aceptados por bancos y reguladores.

Especulación, prefetching y diseño de CPU

  • Preocupación más amplia de que las técnicas especulativas y los prefetchers son intrínsecamente riesgosos para la criptografía.
  • Sugerencias: banderas o modos de hardware para criptografía de tiempo constante, hardware seguro dedicado (TPM, Secure Enclave, HSMs, claves hardware), o incluso núcleos/CPUs dedicados a código “de confianza vs no confiable”.
  • Otros argumentan que la especulación es esencial para el rendimiento moderno; la verdadera carencia es un modelo formal de canal lateral.

Otras reacciones

  • Algunos acusan el encuadre “no puede parchearse” de ser clickbait; otros señalan la falta de cualquier mitigación conocida para M1/M2 pese a la divulgación coordinada.
  • Debate sobre la “seguridad por oscuridad” y sobre si arquitecturas más abiertas (p. ej., RISC-V) mejoran la confianza en la raíz de hardware.