Un nuevo informe de seguridad ha revelado una vulnerabilidad grave afectando a varias distribuciones Linux. Esta vulnerabilidad permite acceder al sistema eludiendo la protección del cifrado de disco, lo cual pone en evidencia una carencia en las medidas de «endurecimiento» de algunos sistemas.
El papel del initramfs
El initramfs (Initial RAM Filesystem) es un sistema de archivos mínimo cargado en memoria durante el arranque. Su función es preparar el entorno para montar el disco raíz, especialmente cuando está cifrado, y entregar el control al sistema operativo. Aunque no es estrictamente necesario, puede ser indispensable para arrancar el sistema en configuraciones sencillas donde la partición raíz tiene formato ext4 y reside en un dispositivo de almacenamiento local.
El ataque «evil maid»
Este tipo de ataque, conocido como evil maid attack, requiere acceso físico al equipo. Sin embargo, demuestra que el cifrado del disco no garantiza una protección total si otros elementos del arranque permanecen vulnerables o sin firmar.
Acceso a la shell de depuración
La investigación ha sido llevada a cabo por el equipo de seguridad de ERNW Insinuator, y demuestra que es posible obtener acceso a una shell de depuración (debug shell) desde el entorno de arranque (initramfs). Esto se logra simplemente introduciendo varias veces una contraseña de cifrado incorrecta. A partir de ahí, el atacante puede modificar el sistema sin necesidad de autenticarse ni romper el cifrado.
Impacto por distribución
| Distribución | ¿Shell accesible? | ¿USB accesible? | ¿Ataque viable? |
|---|---|---|---|
| Ubuntu 25.04 | Sí (tras 3 intentos) | Sí | ✅ |
| Debian 12 | Sí (tras tiempo de espera) | Sí | ✅ |
| Fedora 42 / AlmaLinux 10 | Sí (rescue mode vía GRUB) | No (por defecto) | ⚠️ Parcial |
| OpenSUSE Tumbleweed | No (boot cifrado) | No | ❌ |
⚠️ Parcial: requiere pasos adicionales para obtener herramientas o cargar módulos USB.
Cómo mitigar el riesgo
Mitigar esta vulnerabilidad es posible y relativamente sencillo, aunque requiere atención técnica:
- 1. Desactivar el acceso a la shell de emergencia:
- En sistemas Ubuntu: Añadir
panic=0al parámetro de arranque del kernel. - En sistemas Red Hat/Fedora: Añadir
rd.shell=0 rd.emergency=haltpara evitar shells automáticas.
- En sistemas Ubuntu: Añadir
- 2. Cifrar la partición de arranque (boot):
Solo algunas distribuciones, como OpenSUSE en configuraciones avanzadas, cifran el /boot. Esto impide modificar initramfs sin la clave.
- 3. Usar imágenes firmadas (Unified Kernel Images):
Un enfoque más robusto consiste en usar imágenes UKI (Unified Kernel Images), donde el kernel, initramfs y el cargador están firmados como una sola unidad.
- 4. Configurar contraseñas para arrancar el sistema:
No solo para modificar entradas del GRUB, sino para arrancar el sistema en sí.
Dicho lo cual, que no cunda el pánico. Este es, como la mayoría, uno de esos problemas que requiere de acceso físico al dispositivo para ser explotado, por lo que sí, es una amenaza real, pero no está dirigida ni puede tener una incidencia reseñable para el común de los usuarios. Porque si hay acceso físico… Ahora bien, el riesgo existe y es responsabilidad de las distribuciones darle solución.