Revelouse información sobre dúas vulnerabilidades do cargador de arranque GRUB2, que poden levar á execución de código cando se usan fontes especialmente deseñadas e se procesan determinadas secuencias Unicode. As vulnerabilidades pódense utilizar para evitar o mecanismo de arranque verificado de UEFI Secure Boot.
Vulnerabilidades identificadas:
- CVE-2022-2601 - Un desbordamento do búfer na función grub_font_construct_glyph() ao procesar fontes especialmente deseñadas no formato pf2, que ocorre debido a un cálculo incorrecto do parámetro max_glyph_size e á asignación dunha área de memoria que é obviamente máis pequena da necesaria para acomodar os glifos.
- CVE-2022-3775 Prodúcese unha escritura fóra dos límites ao renderizar algunhas secuencias Unicode cunha fonte de estilo especial. O problema está no código de procesamento da fonte e é causado pola falta de comprobacións adecuadas para garantir que o ancho e o alto do glifo coincidan co tamaño do mapa de bits dispoñible. Un atacante pode crear a entrada de tal forma que faga que a cola dos datos se escriba no exterior do búfer asignado. Nótase que a pesar da complexidade de explotar a vulnerabilidade, non se exclúe levar o problema á execución do código.
A corrección publicouse como un parche. O estado de eliminación de vulnerabilidades nas distribucións pódese avaliar nestas páxinas: Ubuntu, SUSE, RHEL, Fedora, Debian. Para solucionar os problemas en GRUB2, non abonda con actualizar o paquete; tamén terás que xerar novas sinaturas dixitais internas e actualizar instaladores, cargadores de arranque, paquetes do núcleo, firmware fwupd e capa shim.
A maioría das distribucións de Linux usan unha pequena capa shim asinada dixitalmente por Microsoft para o arranque verificado no modo de arranque seguro UEFI. Esta capa verifica GRUB2 co seu propio certificado, o que permite que os desenvolvedores de distribución non teñan todos os kernels e actualizacións de GRUB certificados por Microsoft. As vulnerabilidades en GRUB2 permítenche lograr a execución do teu código na fase posterior á verificación exitosa do shim, pero antes de cargar o sistema operativo, encaixándote na cadea de confianza cando o modo de arranque seguro está activo e gañando control total sobre o proceso de arranque posterior, incluíndo cargando outro SO, modificando os compoñentes do sistema operativo e evitando a protección de bloqueo.
Para bloquear a vulnerabilidade sen revogar a sinatura dixital, as distribucións poden usar o mecanismo SBAT (UEFI Secure Boot Advanced Targeting), que é compatible con GRUB2, shim e fwupd na maioría das distribucións de Linux populares. SBAT desenvolveuse conxuntamente con Microsoft e implica engadir metadatos adicionais aos ficheiros executables dos compoñentes UEFI, que inclúe información sobre o fabricante, o produto, o compoñente e a versión. Os metadatos especificados están certificados cunha sinatura dixital e pódense incluír por separado nas listas de compoñentes permitidos ou prohibidos para UEFI Secure Boot.
SBAT permítelle bloquear o uso de sinaturas dixitais para números de versión de compoñentes individuais sen ter que revogar as claves para o arranque seguro. O bloqueo de vulnerabilidades a través de SBAT non require o uso dunha lista de revogación de certificados UEFI (dbx), pero realízase no nivel de substitución da chave interna para xerar sinaturas e actualizar GRUB2, shim e outros artefactos de arranque proporcionados polas distribucións. Antes da introdución de SBAT, actualizar a lista de revogación de certificados (dbx, UEFI Revocation List) era un requisito previo para bloquear completamente a vulnerabilidade, xa que un atacante, independentemente do sistema operativo empregado, podía utilizar medios de arranque cunha antiga versión vulnerable de GRUB2. certificado mediante unha sinatura dixital, para comprometer o arranque seguro UEFI.
Fonte: opennet.ru