Se publicó un conjunto de parches que corrige 6 vulnerabilidades en el cargador GRUB2, la mayoría de las cuales llevan a un acceso a la memoria después de su liberación (use-after-free). Los problemas potencialmente identificados pueden ser utilizados para eludir el mecanismo de verificación de arranque UEFI Secure Boot. El estado de la solución de vulnerabilidades en las distribuciones se puede evaluar en estas páginas: Debian, Ubuntu, SUSE, RHEL, Arch y Fedora. Para solucionar los problemas en GRUB2, no es suficiente actualizar solo el paquete, también es necesario generar nuevas firmas digitales internas y actualizar los instaladores, cargadores, paquetes del núcleo, firmware fwupd y la capa shim.
Vulnerabilidades detectadas:
- CVE-2025-61661 — escritura fuera del límite del búfer en la función grub_usb_get_string(), que puede ser explotada al procesar cadenas en codificación UTF-8 y UTF-16, transmitidas al conectar dispositivos USB. El problema es causado por el hecho de que el búfer se asignó en función del tamaño de la cadena especificado en el primer mensaje del dispositivo USB, mientras que el tamaño calculado al realizar la conversión de codificación se basaba en las operaciones de lectura posteriores del dispositivo USB. Por lo tanto, para el ataque se puede utilizar un dispositivo USB modificado que originalmente devuelve un valor subestimado del tamaño.
- CVE-2025-61663, CVE-2025-61664, CVE-2025-54770, CVE-2025-61662 — falta de limpieza de los controladores de comandos «normal», «normal_exit», «net_set_vlan» y «gettext» al descargar los módulos «normal», «net» y «gettext», lo que crea condiciones para un acceso a la memoria después de su liberación (use-after-free) en caso de que se ejecuten los comandos marcados después de la descarga de los módulos correspondientes. Se encontraron vulnerabilidades similares también para los comandos «functional_test» y «all_functional_test», pero no se les asignaron identificadores CVE, ya que estos comandos pertenecen a la biblioteca de pruebas y no deberían estar incluidos en las compilaciones de trabajo.
- CVE-2025-54771 — error en el conteo de referencias a las estructuras «fs» en la función grub_file_close(), lo que conduce a un acceso a la memoria después de su liberación (use-after-free).
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
