Se ha dado a conocer información sobre una vulnerabilidad que fue detectada en parches para el gestor de arranque GRUB2 preparado por Red Hat. Catalogada ya bajo CVE-2023-4001 la vulnerabilidad permite que muchos sistemas con UEFI omitan la verificación de contraseña establecida en GRUB2 para restringir el acceso al menú de inicio o a la línea de comandos del cargador de inicio.

Sobre la vulnerabilidad se menciona que esta se debe a un cambio agregado por Red Hat al paquete GRUB2 incluido con RHEL y Fedora, por lo que el problema no aparece en el proyecto principal de GRUB2 y solo afecta a las distribuciones que han aplicado estos parches adicionales suministrados por Red Hat.

Y es que la función de protección con contraseña en GRUB se utiliza para salvaguardar las entradas del menú de inicio y el shell de línea de comandos del administrador de inicio de GRUB. Este mecanismo, cuando está activado junto con una contraseña BIOS/UEFI, protege a los equipos de usuarios no autorizados que intentan iniciar otro sistema operativo o escalar privilegios en un sistema operativo instalado.

La configuración de la contraseña en GRUB se logra mediante dos comandos principales: “password” and “password_pbkdf2“. Estos comandos crean un usuario con una contraseña específica o su hash, y solo aquellos usuarios que figuran en la variable de entorno «superusers» pueden editar las entradas del menú de inicio y ejecutar comandos en el shell de GRUB.

El problema radica en un error en la lógica de cómo el cargador de arranque utiliza el UUID para encontrar un dispositivo que contenga un archivo de configuración con contraseña, como «/boot/efi/EFI/fedora/grub.cfg». Este error permite a un usuario con acceso físico a la computadora conectar una unidad externa, como una memoria USB, y configurarla con un UUID que coincida con el identificador de la partición de inicio/arranque del sistema atacado.

En muchos sistemas UEFI, las unidades externas se procesan primero y se colocan en la lista de dispositivos detectados antes que las unidades estacionarias. Por lo tanto, la partición /boot preparada por el atacante tendrá una mayor prioridad de procesamiento y GRUB2 intentará cargar el archivo de configuración desde esta partición.

Al utilizar el comando «search» en GRUB2 para localizar una partición, solo se determina la primera coincidencia de UUID, deteniendo la búsqueda posterior. Si el archivo de configuración principal no se encuentra en una partición en particular, GRUB2 emitirá un símbolo del sistema, otorgando al usuario control total sobre el resto del proceso de arranque.

Los usuarios sin privilegios pueden conocer el valor UUID del volumen «/boot», lo que les permite potencialmente explotar esta vulnerabilidad. Al manipular la secuencia de dispositivos de bloque durante el arranque, como mediante la conexión de una unidad extraíble con un UUID duplicado, los usuarios pueden eludir la protección con contraseña de GRUB y acceder al shell sin autenticación.

La utilidad «lsblk» puede ser utilizada para determinar el UUID de una partición por parte de un usuario local sin privilegios, pero un usuario externo que no tiene acceso al sistema pero puede observar el proceso de arranque puede, en algunas distribuciones, determinar el UUID a partir del diagnóstico y mensajes que se muestran durante el arranque. Red Hat ha abordado la vulnerabilidad agregando un nuevo argumento al comando «search» que permite que la operación de escaneo UUID se vincule solo a los dispositivos de bloqueo utilizados para ejecutar el administrador de arranque (es decir, la partición /boot solo debe estar en el mismo unidad como partición del sistema EFI).

Un enfoque alternativo (pero no implementado) sería usar algo que no esté expuesto a usuarios sin privilegios como firma para ubicar el volumen “/boot”. Podría ser un archivo con un nombre aleatorio que reside en un directorio con permisos restringidos.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Fuentes:
https://blog.desdelinux.net/una-vulnerabilidad-en-grub2-permitia-omitir-la-verificacion-de-contrasena/