O Secure Boot Advanced Targeting (SBAT) é uma adição recente ao ecossistema de segurança do Linux, projetada para aprimorar o processo de inicialização segura em sistemas com Secure Boot habilitado. Desenvolvido em colaboração mútua entre Microsoft e a Comunidade Linux, para lidar com as limitações do atual processo de verificação de inicialização, o SBAT oferece uma abordagem mais robusta e flexível, garantindo que os sistemas Linux mantenham-se protegidos contra ameaças que exploram vulnerabilidades no processo de boot.
Note que este post é dividido em duas partes, sendo o primeiro bloco com explicações para qualquer usuário entender e o segundo informações mais técnicas para quem precisa compreender o funcionamento detalhado do SBAT.
O que é o SBAT e por que ele é importante?
O SBAT foi introduzido como uma resposta às crescentes ameaças de segurança que afetam a cadeia de inicialização dos sistemas operacionais. O objetivo principal do SBAT é permitir que os sistemas operacionais Linux verifiquem a integridade dos componentes de inicialização de maneira mais granular e eficiente. Com o SBAT, é possível atualizar e revogar partes específicas do processo de inicialização sem afetar a funcionalidade geral do sistema, o que torna a resposta a vulnerabilidades mais ágil e menos disruptiva.
Como funciona o SBAT?
O SBAT opera adicionando metadados específicos a cada componente envolvido no processo de inicialização. Esses metadados incluem versões e identificadores que permitem ao sistema operacional validar cada componente antes de permitir a execução. Caso um componente seja comprometido, o SBAT facilita a revogação seletiva, garantindo que apenas a parte vulnerável seja bloqueada, enquanto o restante do sistema continua operando normalmente.
Comentário importante para usuários de dual boot
É crucial que as distribuições Linux atualizem o GRUB, o gerenciador de boot amplamente utilizado, para compatibilidade com o SBAT. Sem essa atualização, usuários que mantêm configurações de dual boot com o Windows podem enfrentar erros de inicialização, dificultando ou até mesmo impedindo o acesso ao sistema. Essa atualização do GRUB garante que ambos os sistemas operacionais coexistam de maneira harmoniosa, mesmo com as novas medidas de segurança introduzidas pelo SBAT.
Benefícios e desafios
Entre os benefícios do SBAT estão a maior flexibilidade na gestão de componentes de boot e a melhoria na segurança geral do sistema. No entanto, a implementação do SBAT também traz desafios, como a necessidade de manter uma base de dados atualizada de componentes confiáveis e a complexidade adicional que ele pode introduzir na configuração inicial do sistema.
Detalhes técnicos do SBAT e como ele funciona na prática
No ecossistema de PCs, o UEFI Secure Boot é geralmente configurado para confiar em duas autoridades principais para a assinatura de código de inicialização UEFI: a Microsoft UEFI Certificate Authority (CA) e a Windows CA. Quando um código malicioso ou comprometido é detectado, as implementações compatíveis com UEFI fornecem dois mecanismos de revogação: revogação de certificado de assinatura ou revogação por hash de imagem. A especificação UEFI, no entanto, não oferece mecanismos adicionais de revogação amplamente testados.
A revogação por certificado de assinatura não é prática para as CAs da Microsoft e do Windows UEFI, pois revogaria muitas aplicações e drivers UEFI, especialmente para ROMs de Opção. Isso se aplica até mesmo aos certificados de folha da UEFI CA, que geralmente assinam um ano inteiro de imagens UEFI. Como resultado, as revogações UEFI têm sido realizadas por meio de hash de imagem.
O bootloader UEFI shim oferece um nível de abstração na assinatura digital, permitindo que mais autoridades participem do UEFI Secure Boot. Os certificados do shim geralmente assinam aplicações UEFI direcionadas, permitindo a revogação baseada em certificados quando faz sentido. Durante o incidente de segurança “BootHole” (CVE-2020-10713), três certificados e 150 hashes de imagem foram adicionados ao banco de dados de revogação do UEFI Secure Boot (dbx) na arquitetura x64 popular. Esse único evento de revogação consumiu 10kB dos 32kB disponíveis no dbx, ou cerca de um terço da capacidade de armazenamento de revogação disponível em plataformas UEFI. Devido à forma como o UEFI mescla listas de revogação, este evento, juntamente com revogações anteriores, resultou em um dbx com quase 15kB, aproximando-se de 50% da capacidade.
O tamanho significativo do evento de revogação do BootHole deve-se à ineficiência da revogação por hash de imagem quando há uma vulnerabilidade em um componente popular assinado por várias autoridades, muitas vezes com várias versões.
Notícias Relacionadas
Xiaomi tri-dobrável
Xiaomi também lançará um smartphone tri-dobrável em breve
Os smartphones dobráveis já têm um mercado bastante sólido. A cada ano, vemos melhores dobradiças, melhores formatos e ajustes de design. Recentemente, por exemplo, a Huawei lançou o primeiro smartphone dobrável em três partes. Agora, é a vez da Xiaomi trazer o seu primeiro tri-dobrável para o mercado. Xiaomi tri-dobrável As telas tri-dobráveis podem ser […]
Jogo de arcade
Como instalar o Make Them Fall no Ubuntu, Fedora, Debian, RHEL, Mageia e mais
Make Them Fall é um jogo de distância desafiador que testa suas habilidades multitarefa. Controle até 6 bonecos de palito caindo e evite espinhos e obstáculos. Neste tutorial, saiba como instalar o Make Them Fall no Linux, usando pacotes Flatpak. Escolha entre seis níveis de dificuldade e veja quanto tempo você consegue durar. Jogue sozinho […]
Desafios e oportunidades de melhoria
Coordenar a revogação do BootHole exigiu meses de planejamento, implementação e testes, multiplicados pelo número de autoridades, implantações e dispositivos. O processo ainda não está concluído, e espera-se que dure muitos meses, com um longo período de atualizações e testes que pode levar anos.
Além disso, quando bugs ou recursos requerem atualizações no UEFI shim, o número de imagens assinadas se multiplica pelo número de autoridades, resultando em um aumento na complexidade e na carga de trabalho.
Dado o custo e a interrupção consideráveis de um evento de revogação como o BootHole, e o aumento da atividade dos pesquisadores de segurança no espaço do UEFI Secure Boot, é necessário tomar medidas para melhorar significativamente esse processo. A atualização das capacidades de revogação na especificação UEFI e nas implementações de firmware do sistema levará anos para ser implementada no ecossistema. Assim, o foco deste documento está em melhorias que podem ser feitas no UEFI shim, compatíveis com as implementações UEFI existentes. O Shim pode evoluir mais rapidamente do que o ecossistema de firmware do sistema UEFI, ao mesmo tempo que proporciona um grande impacto no ecossistema de Secure Boot do UEFI em uso.
Melhoria na eficiência de revogação com múltiplas versões vulneráveis
Quando uma vulnerabilidade afeta várias versões, pode ser mais eficiente revogar por versão e simplesmente modificar a entrada de revogação para ajustar a versão cada vez que uma vulnerabilidade é detectada. Isso evita o uso excessivo de espaço no dbx e melhora a gestão da segurança.
Melhoria na eficiência de revogação com múltiplas variações de Shim
Quando uma nova versão do shim é lançada para corrigir bugs ou adicionar recursos, no modelo atual, o número de imagens assinadas é multiplicado pelo número de autoridades. Padronizar uma única imagem compartilhada por todas as autoridades poderia reduzir drasticamente o número de revisões de shim, simplificando o processo e aumentando a eficiência.
Revogação baseada em número de geração
A Microsoft propôs um novo mecanismo denominado UEFI Secure Boot Advanced Targeting (SBAT), que introduz a revogação baseada em número de geração. Isso requer que os artefatos de inicialização contenham metadados que incluam informações sobre o fornecedor, a família do produto, o componente, a versão e o número de geração. Esses metadados, protegidos por assinatura digital, permitem uma revogação mais granular e eficiente, substituindo muitos hashes de imagem por uma única entrada com números de geração de segurança.
Cenários de revogação baseada em geração
Os produtos e componentes envolvidos na cadeia de confiança do UEFI Secure Boot são atribuídos a nomes e números de geração mínimos globais e específicos do produto. Esses números de geração garantem que os componentes assinados com um número de geração específico incluam correções para quaisquer vulnerabilidades públicas ou pré-divulgadas. Isso permite que componentes vulneráveis sejam revogados de maneira seletiva, minimizando o impacto para os usuários finais e reduzindo a necessidade de reedições em larga escala.
Considerações técnicas finais
A adoção do SBAT e a implementação de um sistema de revogação mais eficiente são passos essenciais para aprimorar a segurança do UEFI Secure Boot, especialmente em um ambiente onde novas vulnerabilidades são descobertas constantemente. Ao melhorar a eficiência e a eficácia das revogações, é possível minimizar o impacto nos usuários finais e garantir que os sistemas permaneçam seguros contra ameaças emergentes. O SBAT representa uma evolução significativa no gerenciamento da segurança do UEFI, oferecendo uma solução mais escalável e adaptável para o futuro.
Essa abordagem também reflete a necessidade contínua de colaboração entre fornecedores, autoridades de certificação e a comunidade de desenvolvedores para garantir a segurança de todos os componentes envolvidos no processo de inicialização do sistema. Você também consultar a documentação completa.
Distribuições Linux devem atualizar o GRUB para compatibilidade com o SBAT e evitar problemas em sistemas com dual boot com o Windows, garantindo que ambos os sistemas operacionais coexistam sem erros de inicialização.
