Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace pocos días se dio a conocer información sobre un fallo que fue detectado en el controlador que proporciona trabajo con el sistema de archivos NTFS en el gestor de arranque GRUB2, catalogado bajo CVE-2023-4692.

La vulnerabilidad se debe a un error en el código de análisis de un atributo NTFS, que puede usarse para escribir información controlada por el usuario en un área de memoria fuera del búfer asignado. Al procesar una imagen NTFS especialmente diseñada, un desbordamiento conduce a la sobrescritura de parte de la memoria GRUB y también, bajo ciertas condiciones, a daños en el área de memoria del firmware UEFI, lo que potencialmente le permite organizar la ejecución de su código en el gestor de arranque o nivel de firmware.

Se menciona que la vulnerabilidad permite ejecutar a una persona mal intencionada ejecutar código en el nivel del gestor de arranque al acceder a una imagen del sistema de archivos especialmente diseñada. La vulnerabilidad se puede utilizar para omitir el mecanismo de arranque verificado UEFI Secure Boot.

Hola a todos,

Este conjunto de parches contiene un paquete de correcciones para varios fallos de seguridad descubiertos en el código del controlador GRUB2 NTFS recientemente. Los más graves, es decir, potencialmente explotables, tienen CVE asignados.

La mitigación total contra todos los CVE requerirá una actualización con el último SBAT
(Secure Boot Advanced Targeting) . Esta vez no se utilizará la lista de revocación UEFI (dbx) y se revocará la lista rota.

El problema con este tipo de vulnerabilidades en GRUB2, es que permiten lograr la ejecución de 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.

Para bloquear la vulnerabilidad sin revocar la firma digital, se menciona que las distribuciones pueden utilizar el mecanismo SBAT (UEFI Secure Boot Advanced Targeting) , que es compatible con GRUB2, shim y fwupd.

Para quiénes desconocen del mecanismo SBAT, deben saber que este fue desarrollado conjuntamente con Microsoft e implica agregar metadatos adicionales 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 se pueden incluir por separado en las listas de componentes permitidos o prohibidos para UEFI Secure Boot.

Es por ello que debido a que el mecanismo SBAT permite bloquear el uso de firmas digitales para números de versión de componentes individuales sin tener que revocar claves para el arranque seguro. El bloqueo de vulnerabilidades a través de SBAT no requiere el uso de una lista de revocación de certificados UEFI (dbx), sino que se realiza al nivel de reemplazar la clave interna para generar firmas y actualizar GRUB2, shim y otros artefactos de arranque proporcionados por las distribuciones.

Ademas de esta vulnerabilidad, se menciona que también se identificó otra vulnerabilidad (CVE-2023-4693) en el controlador NTFS de GRUB2, que permite leer el contenido de un área de memoria arbitraria al analizar el atributo «$DATA» en una imagen NTFS especialmente diseñada. Entre otras cosas, la vulnerabilidad permite recuperar datos confidenciales almacenados en caché en la memoria o determinar los valores de las variables EFI.

Hasta ahora los problemas solo se han resuelto mediante un parche, aunque para solucionar los problemas en GRUB2, no basta con actualizar el paquete; también es necesario generar nuevas firmas digitales internas y actualizar los instaladores, los cargadores de arranque, los paquetes del kernel, el firmware fwupd y la capa shim.

La mayoría de las distribuciones de Linux utilizan una pequeña capa de corrección, firmada digitalmente por Microsoft, para el arranque verificado en modo UEFI Secure Boot. 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.

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar el estado de la eliminación de las vulnerabilidades en distribuciones se puede valorar en estas páginas: Debian, Ubuntu, SUSE, RHEL y Fedora.