No framework InsydeH2O, usado por muitos fabricantes para criar firmware UEFI para seus equipamentos (a implementação mais comum do UEFI BIOS), foram identificadas 23 vulnerabilidades que permitem a execução de código no nível SMM (System Management Mode), que possui um prioridade mais alta (Anel -2) que o modo hipervisor e anel zero de proteção, além de ter acesso ilimitado a toda a memória. O problema afeta o firmware UEFI usado por fabricantes como Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel e Bull Atos.
A exploração de vulnerabilidades requer acesso local com direitos de administrador, o que torna os problemas populares como vulnerabilidades de segundo nível, usadas após a exploração de outras vulnerabilidades no sistema ou o uso de métodos de engenharia social. O acesso no nível SMM permite executar código em um nível não controlado pelo sistema operacional, que pode ser usado para modificar firmware e deixar códigos maliciosos ou rootkits ocultos no SPI Flash que não são detectados pelo sistema operacional, bem como desabilitar a verificação na fase de inicialização (UEFI Secure Boot, Intel BootGuard) e ataques a hipervisores para contornar mecanismos de verificação de integridade de ambientes virtuais.
A exploração de vulnerabilidades pode ser realizada a partir do sistema operacional usando manipuladores SMI (System Management Interrupt) não verificados, bem como no estágio de pré-execução do sistema operacional durante os estágios iniciais de inicialização ou retorno do modo de suspensão. Todas as vulnerabilidades são causadas por problemas de memória e são divididas em três categorias:
- Callout SMM - execução de seu código com direitos SMM redirecionando a execução de manipuladores de interrupção SWSMI para código fora da SMRAM;
- Corrupção de memória que permite que um invasor grave seus dados em SMRAM, uma área especial de memória isolada na qual o código é executado com direitos SMM.
- Corrupção de memória no código em execução no nível DXE (Driver eXecution Environment).
Para demonstrar os princípios de organização de um ataque, foi publicado um exemplo de exploit que permite, através de um ataque do terceiro ou anel zero de proteção, obter acesso ao DXE Runtime UEFI e executar seu código. A exploração manipula um estouro de pilha (CVE-2021-42059) no driver UEFI DXE. Durante o ataque, o invasor pode colocar seu código no driver DXE, que permanece ativo após a reinicialização do sistema operacional, ou fazer alterações na área NVRAM do SPI Flash. Durante a execução, o código do invasor pode fazer alterações em áreas de memória privilegiadas, modificar os serviços do EFI Runtime e afetar o processo de inicialização.
Fonte: opennet.ru