Se ha revelado información sobre 8 vulnerabilidades en el cargador de arranque GRUB2, que le permiten omitir el mecanismo de arranque seguro UEFI y ejecutar código no verificado, por ejemplo, implementar malware que se ejecuta en el nivel del cargador de arranque o del kernel.
Recordemos que en la mayoría de las distribuciones de Linux, para el arranque verificado en modo UEFI Secure Boot, se utiliza una pequeña capa de compensación, firmada digitalmente por Microsoft. Esta capa verifica GRUB2 con su propio certificado, lo que permite a los desarrolladores de distribuciones no tener cada kernel y actualización de GRUB certificados por Microsoft. Las vulnerabilidades en GRUB2 le permiten lograr la ejecución de su código en la etapa posterior a la verificación exitosa, pero antes de cargar el sistema operativo, ingresando a la cadena de confianza cuando el modo de arranque seguro está activo y obteniendo control total sobre el proceso de arranque posterior, incluido cargar otro sistema operativo, modificar los componentes del sistema operativo y omitir la protección de bloqueo.
Al igual que con la vulnerabilidad BootHole del año pasado, actualizar el gestor de arranque no es suficiente para bloquear el problema, ya que un atacante, independientemente del sistema operativo utilizado, puede usar un dispositivo de arranque con una versión antigua, vulnerable y firmada digitalmente de GRUB2 para comprometer el arranque seguro UEFI. El problema solo se puede resolver actualizando la lista de revocación de certificados (dbx, UEFI Revocation List), pero en este caso se perderá la capacidad de utilizar medios de instalación antiguos con Linux.
En sistemas con firmware que tiene una lista de revocación de certificados actualizada, solo se pueden cargar compilaciones actualizadas de distribuciones de Linux en el modo de arranque seguro UEFI. Las distribuciones deberán actualizar los instaladores, los cargadores de arranque, los paquetes del kernel, el firmware fwupd y la capa shim, generando nuevas firmas digitales para ellos. Los usuarios deberán actualizar las imágenes de instalación y otros medios de arranque, así como cargar una lista de revocación de certificados (dbx) en el firmware UEFI. Antes de actualizar dbx a UEFI, el sistema sigue siendo vulnerable independientemente de la instalación de actualizaciones en el sistema operativo. El estado de las vulnerabilidades se puede evaluar en estas páginas: Ubuntu, SUSE, RHEL, Debian.
Para resolver los problemas que surgen al distribuir certificados revocados, en el futuro está previsto utilizar el mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cuyo soporte se ha implementado para GRUB2, shim y fwupd, y a partir de las próximas actualizaciones se utilizado en lugar de la funcionalidad proporcionada por el paquete dbxtool. SBAT fue desarrollado conjuntamente con Microsoft e implica agregar nuevos metadatos a los archivos ejecutables de los componentes UEFI, que incluyen información sobre el fabricante, producto, componente y versión. Los metadatos especificados están certificados con una firma digital y, además, pueden incluirse en las listas de componentes permitidos o prohibidos para UEFI Secure Boot. Por lo tanto, SBAT le permitirá manipular los números de versión de los componentes durante la revocación sin la necesidad de regenerar claves para el arranque seguro y sin generar nuevas firmas para el kernel, shim, grub2 y fwupd.
Vulnerabilidades identificadas:
- CVE-2020-14372: utilizando el comando acpi en GRUB2, un usuario privilegiado en el sistema local puede cargar tablas ACPI modificadas colocando una SSDT (tabla secundaria de descripción del sistema) en el directorio /boot/efi y cambiando la configuración en grub.cfg. Aunque el modo de arranque seguro está activo, el kernel ejecutará el SSDT propuesto y se puede utilizar para desactivar la protección LockDown que bloquea las rutas de omisión de arranque seguro UEFI. Como resultado, un atacante puede lograr cargar su módulo de kernel o ejecutar código a través del mecanismo kexec, sin verificar la firma digital.
- CVE-2020-25632 es un acceso a memoria de uso después de liberación en la implementación del comando rmmod, que ocurre cuando se intenta descargar cualquier módulo sin tener en cuenta las dependencias asociadas al mismo. La vulnerabilidad no excluye la creación de un exploit que podría llevar a la ejecución de código sin pasar por la verificación de arranque seguro.
- CVE-2020-25647 Una escritura fuera de límites en la función grub_usb_device_initialize() llamada al inicializar dispositivos USB. El problema se puede solucionar conectando un dispositivo USB especialmente preparado que genere parámetros cuyo tamaño no corresponda al tamaño del búfer asignado para las estructuras USB. Un atacante puede lograr la ejecución de código que no está verificado en Secure Boot manipulando dispositivos USB.
- CVE-2020-27749 es un desbordamiento del búfer en la función grub_parser_split_cmdline(), que puede deberse a la especificación de variables de más de 2 KB en la línea de comando de GRUB1. La vulnerabilidad permite que la ejecución de código omita el arranque seguro.
- CVE-2020-27779: el comando cutmem permite a un atacante eliminar un rango de direcciones de la memoria para evitar el arranque seguro.
- CVE-2021-3418: los cambios en shim_lock crearon un vector adicional para explotar la vulnerabilidad CVE-2020-15705 del año pasado. Al instalar el certificado utilizado para firmar GRUB2 en dbx, GRUB2 permitió cargar cualquier kernel directamente sin verificar la firma.
- CVE-2021-20225: Posibilidad de escribir datos fuera de límites al ejecutar comandos con una gran cantidad de opciones.
- CVE-2021-20233: Posibilidad de escribir datos fuera de los límites debido a un cálculo incorrecto del tamaño del búfer al utilizar comillas. Al calcular el tamaño, se supuso que se necesitaban tres caracteres para escapar de una comilla simple, cuando en realidad se necesitaban cuatro.
Fuente: opennet.ru