Revelouse información sobre 8 vulnerabilidades no cargador de arranque GRUB2, que che permiten evitar o mecanismo de arranque seguro UEFI e executar código non verificado, por exemplo, implementar malware que se executa a nivel do cargador de arranque ou do núcleo.
Lembremos que na maioría das distribucións de Linux, para o arranque verificado no modo de arranque seguro UEFI, utilízase unha pequena capa shim, asinada dixitalmente por Microsoft. 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.
Do mesmo xeito que coa vulnerabilidade BootHole do ano pasado, actualizar o cargador de arranque non é suficiente para bloquear o problema, xa que un atacante, independentemente do sistema operativo utilizado, pode utilizar medios de arranque cunha versión antiga, asinada dixitalmente e vulnerable de GRUB2 para comprometer o arranque seguro de UEFI. O problema só se pode resolver actualizando a lista de revogación de certificados (dbx, Lista de revogación UEFI), pero neste caso perderase a posibilidade de utilizar medios de instalación antigos con Linux.
Nos sistemas con firmware que teña unha lista de revogación de certificados actualizada, só se poden cargar compilacións actualizadas de distribucións de Linux no modo de arranque seguro UEFI. As distribucións terán que actualizar os instaladores, os cargadores de arranque, os paquetes do núcleo, o firmware fwupd e a capa shim, xerando novas sinaturas dixitais para eles. Os usuarios deberán actualizar as imaxes de instalación e outros medios de arranque, así como cargar unha lista de revogación de certificados (dbx) no firmware UEFI. Antes de actualizar dbx a UEFI, o sistema segue sendo vulnerable independentemente da instalación de actualizacións no sistema operativo. O estado das vulnerabilidades pódese avaliar nestas páxinas: Ubuntu, SUSE, RHEL, Debian.
Para solucionar os problemas que xurdan ao distribuír certificados revogados, no futuro está previsto empregar o mecanismo SBAT (UEFI Secure Boot Advanced Targeting), cuxo soporte se implantou para GRUB2, shim e fwupd, e que a partir das próximas actualizacións serán usado en lugar da funcionalidade proporcionada polo paquete dbxtool. SBAT desenvolveuse conxuntamente con Microsoft e implica engadir novos metadatos aos ficheiros executables dos compoñentes UEFI, que inclúe información sobre o fabricante, produto, compoñente e versión. Os metadatos especificados están certificados cunha sinatura dixital e pódense incluír ademais nas listas de compoñentes permitidos ou prohibidos para o arranque seguro de UEFI. Así, SBAT permitirache manipular os números de versión dos compoñentes durante a revogación sen necesidade de rexenerar as claves para o arranque seguro e sen xerar novas sinaturas para o núcleo, shim, grub2 e fwupd.
Vulnerabilidades identificadas:
- CVE-2020-14372: usando o comando acpi en GRUB2, un usuario privilexiado do sistema local pode cargar táboas ACPI modificadas colocando unha SSDT (Táboa de descrición do sistema secundaria) no directorio /boot/efi e cambiando a configuración en grub.cfg. Aínda que o modo de arranque seguro está activo, o SSDT proposto será executado polo núcleo e pódese usar para desactivar a protección LockDown que bloquea as rutas de omisión de arranque seguro de UEFI. Como resultado, un atacante pode conseguir cargar o seu módulo do núcleo ou executar código a través do mecanismo kexec, sen comprobar a sinatura dixital.
- CVE-2020-25632 é un acceso á memoria libre de uso posterior na implementación do comando rmmod, que se produce cando se intenta descargar algún módulo sen ter en conta as dependencias asociadas a el. A vulnerabilidade non exclúe a creación dun exploit que poida levar á execución de código sen pasar a verificación de arranque seguro.
- CVE-2020-25647 Unha escritura fóra dos límites na función grub_usb_device_initialize() chamada ao inicializar dispositivos USB. O problema pódese explotar conectando un dispositivo USB especialmente preparado que produce parámetros cuxo tamaño non se corresponde co tamaño do búfer asignado ás estruturas USB. Un atacante pode lograr a execución de código que non se verifica en Secure Boot manipulando dispositivos USB.
- CVE-2020-27749 é un desbordamento do búfer na función grub_parser_split_cmdline(), que se pode producir especificando variables de máis de 2 KB na liña de comandos de GRUB1. A vulnerabilidade permite que a execución de código evite o arranque seguro.
- CVE-2020-27779: o comando cutmem permite que un atacante elimine unha serie de enderezos da memoria para evitar o arranque seguro.
- CVE-2021-3418: os cambios en shim_lock crearon un vector adicional para explotar a vulnerabilidade CVE-2020-15705 do ano pasado. Ao instalar o certificado usado para asinar GRUB2 en dbx, GRUB2 permitiu que calquera núcleo se cargase directamente sen verificar a sinatura.
- CVE-2021-20225 - Posibilidade de escribir datos fóra dos límites ao executar comandos cun número moi grande de opcións.
- CVE-2021-20233 - Posibilidade de escribir datos fóra dos límites debido a un cálculo incorrecto do tamaño do búfer ao usar comiñas. Ao calcular o tamaño, supoñíase que eran necesarios tres caracteres para escapar dunha única comiña, cando en realidade eran necesarios catro.
Fonte: opennet.ru