Hace un par de días me topé con una noticia que me hizo poner los pelos de punta. Un tipo llamado Ingo Blechschmidt descubrió que, desde Linux 6.9 (mayo de 2024), los sistemas con cifrado LUKS han estado dejando las llaves de encriptación en la RAM al suspender la máquina. Y no, no es un chiste. Es un bug que estuvo dos años enteros sin que nadie se diera cuenta.
El problema: confiaste en algo que no funcionaba
Si eres de los que usan Linux con disco cifrado, probablemente piensas que al cerrar la tapa de tu laptop las llaves se borran de memoria y tu información queda a salvo. Eso es exactamente lo que debería pasar. El problema es que, desde el kernel 6.9, el proceso que se encarga de eso fallaba en silencio. No tiraba error, no avisaba nada, simplemente no hacía la pega.
La wea es que esto pasó por un refactoring del kernel que parecía inocente: cambiaron cómo se accede a los dispositivos de bloque en el subsistema md. Una movida técnica que parecía buena idea, pero que a la distancia rompió el flujo entre cryptsetup-suspend y el kernel. Resultado: tus llaves seguían ahí, calentitas en la RAM, mientras tu laptop dormía.
¿Qué tan grave es?
Bastante. Si alguien te roba la laptop en suspensión —o la incauta— puede hacer un cold boot attack y extraer las llaves directamente de la memoria. Blechschmidt lo comprobó: armó una VM en QEMU, suspendió, volcó la RAM y ahí estaba la llave, como si nada.
Lo más chistoso —y a la vez más preocupante— es que el fix es de una sola línea. Sí, una línea. Pero estuvo dos años sin que nadie la escribiera porque el sistema fallaba en silencio. No hay logs, no hay advertencias, solo confianza ciega en que la seguridad estaba funcionando.
¿Qué podemos sacar de esto?
Primero, que en la pega de sysadmin no podemos darnos el lujo de asumir que las herramientas de seguridad hacen lo que dicen. Hay que revisar, testear, meter mano. Blechschmidt encontró el bug porque estaba haciendo exactamente eso: revisando código mientras portaba cryptsetup-suspend a NixOS.
Segundo, que los tests automatizados importan. Ya agregó un test a NixOS para que esto no vuelva a pasar, y hay un patch en camino para que cryptsetup avise cuando no pueda hacer su trabajo. Porque preferible es que te grite a que te deje en la oscuridad.
Tercero, y esto es más una reflexión personal: a veces pienso que el open source es más seguro por los ojos sobre el código, pero esta wea demuestra que incluso con miles de ojos, algo tan crítico puede pasar caleta por dos años. No es para desconfiar, es para no dormirse en los laureles.
Mi recomendación: si tienes una laptop con Linux y LUKS, actualiza el kernel apenas salga el patch. Y si eres paranoico como yo, deja de usar suspensión y apaga la máquina cuando la dejas. Es menos cómodo, pero la tranquilidad no tiene precio.
Fuente de inspiración: Linux LUKS Encryption Key Leak on Suspend (Since 6.9) & Secure Suspend Fix
