Fuga de claves LUKS en hibernación: el parche no borra los secretos de la RAM
Una vulnerabilidad en kernels Linux superiores a 6.9 permitía que las claves de cifrado persistieran en memoria tras el sueño.
Ingo Blechschmidt ha detectado que las versiones del kernel de Linux posteriores a la 6.9 no limpiaban las claves de cifrado de disco de la memoria RAM cuando el sistema entraba en modo de suspensión. A pesar de que los administradores habían configurado el sistema para borrar estas credenciales, estas permanecían accesibles en la memoria física del equipo, dejando la puerta abierta a ataques de cold-boot o a la lectura directa de la bus de memoria por parte de un atacante con acceso físico.
El fallo y la solución parcial
El problema surgió tras el lanzamiento de la versión 6.9 en mayo de 2024. Blechschmidt identificó rápidamente la causa técnica y propuso un arreglo que ya ha sido integrado en el código base del kernel. Sin embargo, la solución aplicada no es exhaustiva. El parche actual corrige el comportamiento en ciertos escenarios, pero no garantiza que todas las vías de acceso a las claves LUKS sean cerradas de forma uniforme en todas las configuraciones posibles del sistema.
Para los responsables de seguridad en infraestructuras críticas o equipos portátiles con datos sensibles, esto implica una revisión de las suposiciones sobre la protección en reposo. La suspensión de Linux nunca ha sido una barrera criptográfica impenetrable frente a un atacante con herramientas de hardware, pero el fallo rompía la expectativa de que, al menos, el borrado de claves se ejecutara según lo configurado. Ahora, aunque haya un arreglo preliminar, la persistencia de los secretos en la memoria sigue siendo un vector de riesgo que no puede ignorarse en entornos de alto valor.
El incidente recuerda que la seguridad en las capas de infraestructura depende de detalles minuciosos en el kernel. Mientras no se implante una solución completa que cubra todos los flujos de suspensión, las organizaciones que dependen de LUKS para su cifrado en reposo deberían considerar medidas adicionales, como la verificación manual de la limpieza de la memoria o el uso de herramientas de bloqueo más estrictas al apagar o suspender las máquinas.
