No cargador de arranque GRUB2 8 vulnerabilidades. O máis perigoso (), que recibe o nome en clave BootHole, evitar o mecanismo de arranque seguro UEFI e instalar malware non verificado. A peculiaridade desta vulnerabilidade é que para eliminala non abonda con actualizar GRUB2, xa que o atacante pode utilizar soportes de arranque cunha versión vulnerable antiga certificada por sinatura dixital. Un atacante pode comprometer o proceso de verificación non só de Linux, senón tamén doutros sistemas operativos, incluíndo .
O problema só se pode resolver actualizando o sistema (dbx, Lista de revogación UEFI), pero neste caso perderase a posibilidade de usar medios de instalación antigos con Linux. Algúns fabricantes de equipos xa incluíron unha lista actualizada de certificados de revogación no seu firmware; nestes sistemas, só se poden cargar compilacións actualizadas de distribucións de Linux no modo de arranque seguro UEFI.
Para eliminar a vulnerabilidade nas distribucións, tamén terás 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.
Vulnerabilidade un desbordamento do búfer que se pode explotar para executar código arbitrario durante o proceso de inicio.
A vulnerabilidade prodúcese ao analizar o contido do ficheiro de configuración grub.cfg, que normalmente se atopa no ESP (EFI System Partition) e pode ser editado por un atacante con dereitos de administrador sen violar a integridade do shim asinado e os ficheiros executables GRUB2. Por mor de no código do analizador de configuración, o xestor de erros de análise fatal YY_FATAL_ERROR só amosaba un aviso, pero non rematou o programa. O risco de vulnerabilidade redúcese pola necesidade de ter acceso privilexiado ao sistema; non obstante, o problema pode ser necesario para introducir rootkits ocultos se tes acceso físico ao equipo (se é posible arrancar desde o teu propio medio).
A maioría das distribucións de Linux usan un pequeno , asinado 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. A vulnerabilidade permite, ao cambiar o contido de grub.cfg, conseguir a execución do seu código na fase posterior á verificación exitosa do shim, pero antes de cargar o sistema operativo, encaixarse na cadea de confianza cando o modo de arranque seguro está activo e gañando o control total. durante o proceso de arranque posterior, incluíndo cargar outro SO, modificar os compoñentes do sistema operativo e evitar a protección .
Outras vulnerabilidades en GRUB2:
- — desbordamento do búfer debido á falta de comprobar o tamaño da área de memoria asignada en grub_malloc;
- - un desbordamento de enteiros en grub_squash_read_symlink, que pode levar a que os datos se escriban máis aló do búfer asignado;
- - desbordamento de enteiros en read_section_from_string, o que pode levar a escribir datos máis aló do búfer asignado;
- - un desbordamento de enteiros en grub_ext2_read_link, que pode levar a que os datos se escriban máis aló do búfer asignado;
- — permítelle cargar núcleos sen asinar durante o arranque directo no modo de arranque seguro sen unha capa shim;
- — acceso a unha área de memoria xa liberada (use-after-free) ao redefinir unha función en tempo de execución;
- — desbordamento de enteiros no manejador de tamaño initrd.
Lanzáronse actualizacións do paquete de hotfix para , , и . Para GRUB2 conxunto de parches.
Fonte: opennet.ru