Se han publicado detalles sobre 21 vulnerabilidades en el cargador GRUB2, la mayoría de las cuales conducen a desbordamientos de búfer y pueden ser utilizadas para eludir el mecanismo de arranque seguro UEFI. Los problemas solo se han resuelto hasta ahora a través de parches. El estado de corrección de las vulnerabilidades en las distribuciones se puede evaluar en estas páginas: Debian, Ubuntu, SUSE, RHEL, Fedora. Para solucionar los problemas en GRUB2, no es suficiente simplemente actualizar el paquete, también se requiere generar nuevas firmas digitales internas y actualizar instaladores, cargadores, paquetes del núcleo, firmwares fwupd y la capa shim.
Vulnerabilidades detectadas:
- CVE-2024-45774: escritura fuera del límite del búfer al analizar imágenes JPEG especialmente diseñadas.
- CVE-2024-45776, CVE-2024-45777: desbordamientos de enteros al leer archivos mo especialmente diseñados, que conducen a escrituras fuera del límite del búfer.
- CVE-2024-45778, CVE-2024-45779: desbordamientos de enteros al trabajar con un sistema de archivos BFS dañado, lo que lleva a un desbordamiento de búfer.
- CVE-2024-45780: desbordamiento de entero al procesar archivos tar especialmente diseñados, que provoca escrituras fuera del límite del búfer.
- CVE-2024-45781, CVE-2025-0677: desbordamientos de búfer al trabajar con un sistema de archivos UFS dañado.
- CVE-2024-45782, CVE-2025-1125: desbordamientos de búfer al montar una partición HFS especialmente diseñada.
- CVE-2025-0622: acceso a la memoria después de su liberación al manipular módulos, lo que puede llevar a la ejecución de código por parte del atacante.
- CVE-2025-0624: desbordamiento de búfer durante el arranque de red.
- CVE-2025-0678: desbordamientos de búfer al trabajar con un sistema de archivos Squash4 dañado.
- CVE-2025-0684: desbordamientos de búfer al manipular enlaces simbólicos en el sistema de archivos Reiserfs.
- CVE-2025-0685: desbordamientos de búfer al manipular enlaces simbólicos en el sistema de archivos JFS.
- CVE-2025-0685: desbordamientos de búfer al manipular enlaces simbólicos en el sistema de archivos ROMFS.
- CVE-2025-0689: desbordamientos de búfer al trabajar con una partición UDF especialmente modificada.
- CVE-2025-0690: desbordamientos de búfer al recibir datos especialmente diseñados desde el teclado.
- CVE-2025-1118: eludir el modo de aislamiento Lockdown y extraer contenido arbitrario de la memoria mediante la ejecución del comando dump.
- CVE-2024-45775: falta de comprobación del código de error al asignar memoria al analizar los argumentos suministrados, lo que puede dañar los datos de la IVT (Interrupt Vector Table).
- CVE-2024-45783: acceso a un puntero nulo al montar un sistema de archivos HFS+ incorrecto.
En la mayoría de las distribuciones de Linux, se utiliza una pequeña capa llamada shim, firmada digitalmente por Microsoft, para la verificación de arranque en modo UEFI Secure Boot. Esta capa verifica GRUB2 con su propio certificado, lo que permite a los desarrolladores de distribuciones no tener que certificar cada actualización del núcleo y de GRUB con Microsoft. Las vulnerabilidades en GRUB2 permiten ejecutar código propio en la etapa posterior a la verificación exitosa de shim, pero antes de que se cargue el sistema operativo, infiltrándose en la cadena de confianza con el modo Secure Boot activo y obteniendo control total sobre el proceso de arranque posterior, por ejemplo, para cargar otro sistema operativo, modificar componentes del sistema operativo y eludir la protección Lockdown.
Para bloquear la vulnerabilidad sin revocar la firma digital, las distribuciones pueden utilizar el mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cuyo soporte se ha implementado para GRUB2, shim y fwupd en la mayoría de las distribuciones populares de Linux. SBAT ha sido desarrollado en conjunto con Microsoft e implica la adición de metadatos adicionales a los archivos ejecutables de componentes UEFI, que incluyen información sobre el fabricante, el producto, el componente y la versión. Estos metadatos están firmados digitalmente y pueden incluirse por separado en listas de componentes permitidos o prohibidos para UEFI Secure Boot.
SBAT permite bloquear el uso de firmas digitales para versiones específicas de componentes sin necesidad de revocar claves para Secure Boot. El bloqueo de vulnerabilidades a través de SBAT no requiere el uso de la lista de certificados revocados UEFI (dbx), sino que se realiza a nivel de reemplazo de la clave interna para la formación de firmas y la actualización de GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones. Antes de la implementación de SBAT, la actualización de la lista de certificados revocados (dbx, UEFI Revocation List) era un requisito obligatorio para el bloqueo completo de una vulnerabilidad, ya que un atacante, independientemente del sistema operativo utilizado, podía comprometer UEFI Secure Boot utilizando un medio de arranque con una versión antigua y vulnerable de GRUB2, firmada digitalmente.
Fuente: opennet.ru
