En el controlador que maneja el sistema de archivos NTFS en el cargador GRUB2, se ha identificado una vulnerabilidad (CVE-2023-4692) que permite la ejecución de código personalizado a nivel de cargador al interactuar con una imagen de sistema de archivos especialmente diseñada. Esta vulnerabilidad puede ser utilizada para eludir el mecanismo de arranque verificado UEFI Secure Boot.
La vulnerabilidad se debe a un error en el código de análisis del atributo NTFS «$ATTRIBUTE_LIST» (grub-core/fs/ntfs.c), que puede ser explotado para escribir información controlada por el usuario en una zona de memoria más allá del búfer asignado. Al procesar una imagen NTFS específicamente diseñada, el desbordamiento provoca la reescritura de parte de la memoria de GRUB y, en ciertas condiciones, el deterioro del área de memoria del firmware UEFI, lo que potencialmente permite la ejecución de su código a nivel de cargador o firmware.
Además, en el controlador NTFS de GRUB2 se ha encontrado otra vulnerabilidad (CVE-2023-4693) que permite leer el contenido de áreas de memoria arbitrarias al analizar el atributo «$DATA» en una imagen NTFS especialmente formada. Entre otras cosas, esta vulnerabilidad permite extraer datos confidenciales almacenados en caché en la memoria o determinar los valores de las variables EFI.
Los problemas se han resuelto por ahora solo a través de un parche. El estado de la solución de vulnerabilidades en las distribuciones se puede evaluar en las siguientes páginas: Debian, Ubuntu, SUSE, RHEL, Fedora. Para solucionar los problemas en GRUB2, no es suficiente con actualizar el paquete; también es necesario generar nuevas firmas digitales internas y actualizar instaladores, cargadores, paquetes del núcleo, firmware fwupd y la capa shim.
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 la firma digital para versiones específicas de componentes sin necesidad de revocar las 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), y se lleva a cabo a nivel de reemplazo de la clave interna para generar firmas y actualizar GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones. Hasta la implementación de SBAT, la actualización de la lista de certificados revocados (dbx, UEFI Revocation List) era un requisito indispensable para bloquear completamente la vulnerabilidad, ya que un atacante, independientemente del sistema operativo utilizado, podría comprometer UEFI Secure Boot usando el arranque.
Fuente: opennet.ru
