Intenta hacer sudo menos vulnerable a ataques Rowhammer

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

Un cambio reciente en la base de código de `sudo` introduce constantes numéricas especialmente elegidas con grandes distancias de Hamming para dificultar que estados críticos de autorización se vean alterados por ataques DRAM de tipo Rowhammer. Los comentaristas exploran si este endurecimiento a nivel de software merece la pena dado que Rowhammer es, en esencia, un problema de fiabilidad del hardware, debatiendo compensaciones entre complejidad, rendimiento y modelos de amenaza reales, y sugiriendo alternativas como soporte del compilador, memoria ECC y mejores especificaciones de hardware. El hilo también aborda implicaciones más amplias para el diseño de sistemas seguros y resilientes, desde sistemas embebidos de alta fiabilidad hasta entornos de alojamiento compartido y la nube.

Parche y técnica de programación

  • Ahora sudo usa constantes de 32 bits специально elegidas para los estados de autenticación (SUCCESS, FAILURE, ERROR, etc.) con grandes distancias de Hamming entre ellas.
  • Objetivo: hacer que se requieran muchos cambios específicos de bits para que Rowhammer convierta “denegar” en “permitir”, reduciendo la viabilidad del exploit Mayhem/Rowhammer demostrado.
  • Algunos comentaristas encuentran este estilo de programación defensiva interesante, pero temen que sería un “infierno” aplicarlo de forma general; otros señalan su similitud con ideas de tolerancia a fallos conocidas desde hace tiempo (upsets de evento único, votación, ECC).

Ideas de lenguaje / compilador

  • Varios proponen soporte del compilador: atributos para enums “seguros” cuyas codificaciones maximicen la distancia de Hamming, o modos de hardening que conserven comprobaciones “redundantes” en lugar de optimizarlas fuera.
  • Los enums de C/C++ son complicados por ABI y compatibilidad hacia atrás; Rust y los lenguajes dinámicos podrían soportar estas funciones con más facilidad.
  • Se cita hardbool de GCC como una idea análoga para booleanos.
  • Otros discuten algoritmos para generar códigos de alta distancia; algunos señalan que los valores elegidos por sudo no son matemáticamente óptimos, y que construir códigos óptimos es un problema no trivial de teoría de la codificación.

Efectividad y compensaciones

  • Los partidarios lo presentan como defensa en profundidad: bloquea directamente una ruta conocida de Rowhammer y es apropiado para objetivos de alto valor como binarios setuid.
  • Los escépticos argumentan que solo protege una clase de variable, no aborda otros datos o controles corruptibles y hace el código más difícil de leer y auditar.
  • Algunos señalan que, si un atacante ya tiene ejecución local de código, puede haber rutas de escalada más fáciles, aunque otros responden que el alojamiento compartido, los clústeres y los servidores de juegos aún se benefician del endurecimiento.

Rowhammer, ECC y hardware frente a software

  • Varios comentarios subrayan que Rowhammer es fundamentalmente un problema de DRAM/física. El debate se divide entre:
    • “Arreglarlo en hardware / devolver la RAM defectuosa” frente a
    • “La física y la densidad hacen irrealista una inmunidad perfecta; el software debe ayudar.”
  • ECC y el ECC en el chip reducen, pero no eliminan, el riesgo de Rowhammer; ataques sofisticados y cambios de múltiples bits pueden eludir la corrección, aunque ECC al menos debería activar alertas.
  • Se informa que la DRAM moderna es más vulnerable a medida que aumenta la densidad; las mitigaciones del lado del fabricante, como el refresco dirigido, existen, pero también pueden ser imperfectas o incluso abusadas.

Implicaciones más amplias

  • Se sugiere el mismo patrón (codificaciones de distancia máxima, comprobaciones de coherencia) para microcontroladores y entornos de alta radiación, a fin de detectar rutas de control inválidas y activar reinicios del watchdog.