Desde hace ya algún tiempo, las placas base de los ordenadores incluyen un elemento llamado UEFI, una pequeña interfaz sustituta de la clásica BIOS que funciona como una capa intermedia entre el sistema operativo y el firmware de la placa base, permitiendo llevar a cabo una serie de configuraciones adicionales y siendo mucho más compatible con los protocolos y controladores modernos. Sin embargo, debido a que su naturaleza es mucho más similar a la de un sistema operativo, su sistema de archivos puede accederse desde los sistemas operativos Linux, brindando al usuario y a aplicaciones de acceso a dicho firmware que, por defecto, no debería tener.
Este es un problema del que ya se ha hablado en muchas ocasiones, es más, realizando una simple búsqueda en Google podemos ver cómo ya se habló de ello en launchpad en 2012. El fallo se debe a que cuando instalamos Linux, el sistema de arranque (actualmente systemd en Ubuntu y similares), necesita montar una partición desde donde acceder a la configuración de la BIOS o UEFI del sistema para completar el arranque.
Esta partición se monta en el sistema con permisos de lectura y escritura, de manera que cualquier usuario con permisos podría escribir en ella e incluso borrarla, eliminando un gran número de variables de la UEFI de nuestro sistema que podrían causar desde un fallo en la configuración de la misma hasta una completa pérdida de ella (probablemente irrecuperable) como ocurre en varios equipos MSI.
Este debate vuelve a abrirse una vez más en foros de Arch Linux, donde un usuario asegura que tras haber realizado un borrado completo del equipo, lo que se conoce como «rm -rf /», el sistema no ha vuelto a arrancar, y es que ni siquiera llega a realizar el POST (Power On Self Test) de la placa base, quedando totalmente inutilizada.
Tal como reportan muchos usuarios, los permisos por defecto del directorio efivarfs al teclear el comando «mount | grep efi» son:
- efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
RW nos indica que el directorio tiene permiso de lectura (r) y escritura (w), por lo que cualquier aplicación o comando podrá modificar el contenido de dicho directorio, directorio crítico para el funcionamiento del sistema y que debería estar protegido frente a este tipo de acciones.
Si es obligatorio habilitar los permisos R/X en la UEFI, entonces debemos protegerlo nosotros mismos
Las explicaciones de los desarrolladores tienen su lógica. Durante el arranque es posible que algunas herramientas deban acceder a la configuración de la UEFI, leer datos en ella y escribir algunos parámetros en los ficheros de configuración y registro. Sin embargo, una vez arranca el sistema, dicho directorio ya no es necesario y ni se desmonta ni se cambia por defecto a «solo lectura», por lo que si queremos evitar un desastre debemos protegerlo nosotros mismos.
Si queremos asegurarnos de que nuestra UEFI no sea eliminada aunque realicemos un borrado completo del disco debemos modificar nuestro fichero fstab y añadirle que la ruta de la UEFI se monte en el sistema como solo lectura (ro). Por ejemplo:
# efivars, mount as ro
efivars /sys/firmware/efi/efivars efivarfs ro,nosuid,nodev,noexec,noatime 0 0
De esta manera, el directorio de UEFI se configurará automáticamente como solo lectura, evitando que pueda ser modificado o eliminado por error y garantizando que nuestro sistema no se ve perjudicado por este sencillo, pero peligroso problema de permisos.
- mount | grep efi
- efivarfs on /sys/firmware/efi/efivars type efivarfs (ro,nosuid,nodev,noexec,noatime)
Por el momento, se han abierto solicitudes dentro del desarrollo de systemd para que en el arranque se bloqueen los permisos de escritura en el directorio de UEFI, aunque parece que los desarrolladores no están muy por la labor de llevarlo a cabo.
Obviamente no todas las distribuciones habilitan por defecto los permisos rw del directorio UEFI ni todos los ordenadores se estropean si se borra la información de este directorio. Lo que sí está claro es que hacer un rm -rf / en un sistema Arch Linux en un equipo MSI no tiene final feliz.
Los peligros de rm -rf
Hemos hablado en varias ocasiones de el comando rf -rf, recomendado cuando queremos realizar un borrado seguro del disco, pero es un comando que debemos utilizar con mucho cuidado, ya que, de no hacerlo, es muy probable que terminemos por borrar más datos de los que deberíamos, como ha sido este caso donde se ha borrado el «firmware» de la BIOS.
Otro ejemplo de los peligros de ejecutar rm -rf / es que si tenemos más discos duros conectados y montados en directorios dentro de / estos se borrarán también, ya que raíz incluye todo.
Otro comando, incluso más peligroso que rm -rf donde se asigna un valor 0 a todos los sectores del disco (muy similar a un formateo a bajo nivel) pero más específico para borrar discos y particiones es:
- dd if=/dev/zero of=/dev/sda
¿Eres usuario de Linux? ¿Tu directorio UEFI está perfectamente protegido o está montado con permisos RW?
Quizá te interese:
- Una vulnerabilidad en UEFI permite esquivar Secure Boot en Windows 8.1
- Instala Windows 10 y Ubuntu con arranque dual (Dual-Boot)