Acabei de baixar o Pop!_OS 22.04 LTS (NVIDIA) do site oficial , verifiquei a soma de verificação, pisquei para um pen drive e tentei inicializar a partir dele.
Esqueci de desabilitar o Secure Boot conforme recomendado no site, então, sem surpresa, recebi uma mensagem de erro. No entanto, o conteúdo real da mensagem me surpreendeu:
Assinatura do carregador do sistema operacional encontrada no banco de dados de exclusão do SecureBoot ('dbx'). Todos os dispositivos inicializáveis falharam na verificação de inicialização segura.
Embora eu esperasse que a assinatura NÃO fosse encontrada no banco de dados de assinaturas, não esperava encontrá-la no banco de dados de exclusão .
De acordo com este site :
dbx, o “banco de dados de assinaturas proibidas”. As entradas aqui são tipicamente hashes SHA256 de binários UEFI específicos, ou seja, aquelas coisas que foram assinadas por um certificado na lista “db”, mas posteriormente consideradas ruins (por exemplo, ter uma vulnerabilidade de segurança que compromete o firmware). Portanto, esta é uma lista de “bloqueios”.
Como é que a assinatura do software fornecida pelo System76 pode ter sido válida, mas desde então considerada ruim?
Isso é um sinal de alguma vulnerabilidade potencial no Pop!_OS?
Em meados de 2020, foi encontrada uma vulnerabilidade de segurança conhecida como CVE-2020-10713 ou BootHole . Isso afetou praticamente todas as distribuições que usavam GRUB2 com Secure Boot e tinham o
acpimódulo GRUB incluído em sua configuração compatível com Secure Boot. Como resultado, os pesquisadores de segurança concentraram mais atenção no processo de inicialização para encontrar outras vulnerabilidades semelhantes.Isso levou a que um grupo de outras vulnerabilidades fossem encontradas, corrigidas e publicadas no GRUB2 em março de 2021. Junto com isso, o Debian teve que revogar sua antiga chave de assinatura Secure Boot, criar novas chaves e fazer algumas alterações no processo de assinatura do bootloader. Como o Ubuntu tinha uma infraestrutura de inicialização segura semelhante, eles tiveram que fazer o mesmo .
Outras distribuições que copiam sua infraestrutura Secure Boot do Debian/Ubuntu teriam que fazer o mesmo, já que outra parte do projeto dos pesquisadores de segurança era reunir uma lista de hashes de GRUB e
shimx64.efiversões vulneráveis e revogar as chaves de assinatura do Secure Boot. Essa lista deveria ser adicionada aos bancos de dados de exclusão de futuros firmwares de inicialização segura e, eventualmente, distribuída como atualizações de banco de dados de exclusão de inicialização segura para sistemas existentes.Em 9 de agosto de 2022, a Microsoft lançou uma atualização do banco de dados de exclusão de inicialização segura para Windows que incluía as exclusões para versões vulneráveis do GRUB; uma atualização dbx de inicialização segura também foi lançada para o sistema Linux
fwupd.fwupdmgrParece razoável supor que alguma coordenação entre as distribuições Linux e os fornecedores de sistemas operacionais foi feita para garantir que todos os principais sistemas operacionais fossem cobertos.Agora, se os componentes de inicialização do Pop!_OS estão agora combinando com as listas de exclusão mais recentes, isso indicaria que eles são originários do Debian antes de março de 2021, ou em outras palavras, estão no nível equivalente ao Debian 10.9 ou anterior. Parece que o Pop!_OS pulou algumas atualizações.
Concedido, eles têm uma recomendação para desabilitar o Secure Boot, mas como o Pop!_OS é baseado na versão correspondente do Ubuntu, o suporte do Ubuntu ao Secure Boot indica que um suporte funcional ao Secure Boot deveria ser possível para o Pop!_OS 22.04 LTS também. Talvez o System76 (desenvolvedor do Pop!_OS) tenha optado por ignorar a obtenção de um certificado de inicialização segura da Microsoft? Para mim, isso sugere que o foco do Pop!_OS pode ser mais no estilo do que na substância.
Basicamente, a revogação do Secure Boot de 9 de agosto de 2022 foi feita para eliminar uma falsa sensação de segurança caso você ainda esteja usando componentes vulneráveis: seu sistema não é mais vulnerável do que um sistema sem Secure Boot em primeiro lugar.
Se o seu sistema for fisicamente seguro, não deve haver uma maneira prática para o invasor usar essas vulnerabilidades como uma maneira de entrar no sistema. Mas se você confiar no Secure Boot para tornar os ataques do tipo Evil Maid mais difíceis do que seu nível "esperado" de invasor pode realizar, parece que o Pop!_OS pode ser a escolha errada para esse caso de uso.