No framework InsydeH2O, utilizado por vários fabricantes para criar firmwares UEFI para seu hardware (a implementação mais comum do UEFI BIOS), foram identificadas 23 vulnerabilidades que permitem a execução de código no nível SMM (Modo de Gerenciamento de Sistema), que tem maior prioridade (Ring -2) do que o modo hipervisor e o anel zero de proteção, tendo acesso irrestrito a toda a memória. O problema afeta firmwares UEFI usados por fabricantes como Fujitsu, Siemens, Dell, HP, HPE, Lenovo, Microsoft, Intel e Bull Atos.
Para explorar as vulnerabilidades, é necessário acesso local com direitos de administrador, o que torna os problemas requisitados como vulnerabilidades de segundo nível, que são utilizadas após a exploração de outras vulnerabilidades no sistema ou o uso de métodos de engenharia social. O acesso ao nível SMM permite a execução de código em um nível que não é controlado pelo sistema operacional, o que pode ser usado para modificar firmwares e deixar código malicioso ou rootkits ocultos no SPI Flash, não detectados pelo sistema operacional, além de desabilitar a verificação na fase de inicialização (UEFI Secure Boot, Intel BootGuard) e atacar hipervisores para contornar os mecanismos de verificação de integridade dos ambientes virtuais.
A exploração das vulnerabilidades pode ser realizada a partir do sistema operacional através de manipuladores SMI (System Management Interrupt) não verificados, assim como em etapas anteriores à execução do sistema operacional, durante os estágios iniciais de inicialização ou ao retornar do modo de suspensão. Todas as vulnerabilidades são causadas por problemas de gerenciamento de memória e são divididas em três categorias:
- SMM Callout — execução do próprio código com direitos SMM através do redirecionamento da execução dos manipuladores de interrupção SWSMI para código fora do SMRAM;
- Danos na memória que permitem a um invasor gravar seus dados no SMRAM, uma área de memória especialmente isolada onde o código é executado com direitos SMM.
- Dano na memória no código executado no nível DXE (Driver eXecution Environment).
Para demonstrar os princípios da organização de um ataque, foi publicado um exemplo de exploit que permite, através de um ataque do terceiro ou nulo anel de proteção, obter acesso ao DXE Runtime UEFI e executar seu código. O exploit manipula a sobrecarga de pilha (CVE-2021-42059) no driver UEFI DXE. Durante o ataque, o invasor pode inserir seu código no driver DXE, mantendo atividade após a reinicialização do sistema operacional, ou modificar a área NVRAM na SPI Flash. No processo de execução, o código do invasor pode alterar áreas privilegiadas de memória, modificar serviços EFI Runtime e influenciar o processo de inicialização.
Fonte: opennet.ru
