No carregador GRUB2 8 vulnerabilidades. A mais perigosa (), nomeada de BootHole, contornar o mecanismo UEFI Secure Boot e instalar malware não verificado. A particularidade desta vulnerabilidade é que apenas atualizar o GRUB2 não é suficiente, uma vez que um atacador pode usar um meio de inicialização com uma versão vulnerável antiga, assinada digitalmente. O atacador pode comprometer o processo de verificação não só do Linux, mas também de outros sistemas operacionais, incluindo .
O problema é resolvido apenas atualizando o sistema (dbx, UEFI Revocation List), mas nesse caso, a capacidade de usar antigos meios de instalação com Linux será perdida. Alguns fabricantes de hardware já incluíram em seus firmwares uma lista atualizada de certificados revogados, e nesses sistemas, no modo UEFI Secure Boot, será possível inicializar apenas compilações atualizadas das distribuições Linux.
Para eliminar a vulnerabilidade nas distribuições, também será necessário atualizar instaladores, carregadores, pacotes do kernel, firmwares fwupd e a camada shim, gerando novas assinaturas digitais para eles. Os usuários precisarão atualizar as imagens de instalação e outros meios de inicialização, bem como carregar a lista de certificados revogados (dbx) no firmware UEFI. Até a atualização do dbx no UEFI, o sistema permanece vulnerável, independentemente da instalação de atualizações no SO.
Vulnerabilidade por meio de um estouro de buffer, que pode ser explorado para executar código arbitrário durante o processo de inicialização.
A vulnerabilidade se manifesta ao analisar o conteúdo do arquivo de configuração grub.cfg, que geralmente está localizado na partição ESP (EFI System Partition) e pode ser editado por um invasor com privilégios de administrador, sem comprometer a integridade dos arquivos executáveis assinados shim e GRUB2. Devido a No código do parser de configuração, o manipulador de erros fatais YY_FATAL_ERROR apenas exibia um aviso, mas não encerrava o programa. O risco da vulnerabilidade é reduzido pela necessidade de acesso privilegiado ao sistema; no entanto, o problema pode ser explorado para a implementação de rootkits ocultos com acesso físico ao hardware (caso seja possível inicializar a partir de um meio próprio).
Na maioria das distribuições Linux, é usada uma pequena , assinada digitalmente pela Microsoft. Esta camada verifica o GRUB2 com seu próprio certificado, permitindo que os desenvolvedores de distribuições não assinem cada atualização do kernel e do GRUB na Microsoft. A vulnerabilidade permite, através da alteração do conteúdo de grub.cfg, executar seu próprio código após a verificação bem-sucedida do shim, mas antes da inicialização do sistema operacional, inserindo-se na cadeia de confiança durante o modo Secure Boot ativo e obtendo controle total sobre o processo de inicialização, incluindo o carregamento de outro sistema operacional, a modificação de componentes do sistema operacional e a evasão de proteções. .
Outras vulnerabilidades no GRUB2:
- — estouro de buffer devido à ausência de verificação do tamanho da área de memória alocada em grub_malloc;
- — estouro de inteiro em grub_squash_read_symlink, que pode levar à escrita de dados fora do buffer alocado;
- — estouro de inteiro em read_section_from_string, que pode levar à escrita de dados fora do buffer alocado;
- — estouro de inteiro em grub_ext2_read_link, que pode levar à escrita de dados fora do buffer alocado;
- — permite carregar kernels não assinados ao inicializar diretamente em modo Secure Boot sem a camada shim;
- — acesso a uma área de memória já liberada (uso após liberação) ao redefinir uma função em tempo de execução;
- — estouro de inteiro no manipulador de tamanho initrd.
Atualizações de pacotes com correções foram lançadas para , , e . Para o GRUB2 um conjunto de patches.
Fonte: opennet.ru
