A segurança na inicialização de computadores Linux está prestes a dar um salto significativo. Uma proposta colaborativa, liderada pela Microsoft, busca revolucionar o ciclo de vida do UEFI Secure Boot através de um novo conceito: o SBAT (UEFI Secure Boot Advanced Targeting). Esta inovação visa resolver os desafios persistentes da revogação de firmware e componentes de inicialização, um problema que causou grandes disrupções, como o notório incidente BootHole em 2020.
O UEFI Secure Boot é uma tecnologia fundamental que protege o processo de inicialização de ataques de rootkits e bootkits, garantindo que apenas software confiável seja carregado. No entanto, o método atual de revogação de certificados por hash de imagem tem se mostrado ineficiente e custoso.
Este artigo fará uma análise aprofundada da proposta da Microsoft para o SBAT, explicando como essa nova abordagem baseada em números de geração promete otimizar a segurança, reduzir o impacto de vulnerabilidades e garantir que o Linux e outros sistemas open source possam operar de forma mais resiliente em ambientes com Secure Boot ativado.
O problema da revogação atual: a ineficiência do hash de imagem
Como funciona a revogação de Secure Boot hoje
No modelo atual de UEFI Secure Boot, as plataformas geralmente confiam em duas autoridades principais para assinatura de código:
- A Microsoft UEFI Certificate Authority (CA) – usada por sistemas como o Shim bootloader, essencial para inicializar o Linux.
- A Windows CA – para softwares e drivers do ecossistema Microsoft.
Quando um componente comprometido é identificado, a revogação pode ocorrer de duas formas:
- Revogação por certificado – impraticável quando uma autoridade assina muitos componentes válidos.
- Revogação por hash de imagem – adiciona o hash específico do binário comprometido ao banco de revogação (dbx).
O incidente BootHole: um alerta de ineficiência
A falha BootHole (CVE-2020-10713) foi um divisor de águas. Ela permitia a execução de código arbitrário através de vulnerabilidades no GRUB e no Shim, ambos componentes críticos da cadeia de boot do Linux.
Para mitigar o problema, foi necessário revogar 3 certificados e mais de 150 hashes de imagem no dbx para a arquitetura x64.
Impacto direto:
- O evento ocupou 10 KB dos 32 KB disponíveis no espaço reservado da variável dbx.
- Quando somado a eventos anteriores, o uso do dbx chegou a 15 KB (quase 50% da capacidade total).
Essa abordagem, embora funcional, demonstrou ser ineficiente, escalável apenas até certo ponto, e onerosa em termos de planejamento e manutenção.
Custo e disrupção
- A revogação do BootHole demandou meses de trabalho de engenharia, testes e coordenação entre empresas, distribuições e fabricantes.
- O processo ainda está incompleto em várias plataformas, gerando inconsistência na segurança.
- Sempre que há uma atualização do Shim bootloader, todas as versões anteriores precisam ser mapeadas e revogadas via hash, o que torna o gerenciamento ainda mais complexo.
SBAT: a revolução da revogação baseada em geração
SBAT (UEFI Secure Boot Advanced Targeting): o que é?
O SBAT é um novo mecanismo proposto pela Microsoft, em parceria com desenvolvedores Linux, que permite revogar componentes vulneráveis de forma mais eficiente, utilizando metadados assinados com números de geração.
Funcionamento básico:
- Em vez de adicionar centenas de hashes de imagem ao dbx, o sistema passa a verificar a seção .sbat de uma imagem PE/COFF.
- Essa seção contém informações sobre o componente e sua geração mínima confiável.
- Se o número de geração da imagem for inferior ao exigido, a inicialização é bloqueada.
Estruturas envolvidas:
- A seção .sbat utiliza formato CSV ASCII, contendo campos como
component_name,component_generation, entre outros. - A entrada EFI_CERT_SBAT descreve como esses metadados se integram ao mecanismo de autorização do Secure Boot.
Benefícios da geração baseada em revogação
- Eficiência: um único número de geração pode revogar todas as versões anteriores de um componente vulnerável.
- Economia de espaço: não é necessário adicionar novos hashes, apenas atualizar a entrada existente com um número maior.
- Menos disrupção: reduz o tempo e o custo de engenharia para corrigir falhas críticas.
- Flexibilidade: permite revogação global (para todas as distribuições) ou específica (para um fork ou versão de uma distro).
- Escalabilidade: o modelo funciona bem mesmo em ambientes com centenas de versões customizadas do Shim ou GRUB.
Cenários SBAT: flexibilidade para produtos e componentes
Produtos e componentes
A proposta SBAT distingue entre:
- Produtos (ex:
fedora,debian,vendorC) – relacionados à distribuição ou organização. - Componentes (ex:
shim,grub,kernel) – as partes individuais da cadeia de inicialização.
Número de geração global versus produto-específico
- Geração global: revoga todas as instâncias de um componente específico (ex:
grub,3). - Geração produto-específico: afeta apenas uma versão vinculada a um produto (ex:
grub.vendorC,2).
Esse modelo evita disrupções desnecessárias. Um bug exclusivo de uma distro pode ser corrigido e revogado apenas para ela, sem afetar o ecossistema inteiro.
Exemplo: fornecedor com fork de projeto
Imagine o Vendor C mantendo um fork do GRUB. Se um bug afeta apenas esse fork:
- O número de geração global permanece o mesmo.
- Apenas o número de geração para
grub.vendorCé incrementado no dbx.
Isso mantém o escopo de revogação mínimo e preserva o espaço da variável UEFI.
Aposentando releases assinadas e chaves de fornecedores
Desativando produtos com suporte encerrado (EoSL)
Componentes que atingiram o fim do ciclo de vida (EoSL) não devem continuar aptos a inicializar com UEFI Secure Boot.
Solução com SBAT:
- Aumentar o número de geração do produto para além do último binário assinado.
- Impedir o carregamento de versões antigas mesmo que tecnicamente ainda assinadas.
Isso também vale para releases beta ou experimentais, aumentando a higiene de segurança do ecossistema.
Padronização de chaves de fornecedores
O modelo ideal é que cada fornecedor use:
- Um único Shim assinado, e
- Arquivos separados de chaves por produto (
<Vendor>_key.EFI).
Essas chaves podem ser revogadas com SBAT se forem comprometidas, sem precisar invalidar toda a autoridade CA.
Suporte do kernel ao SBAT e metadados de revogação
SBAT no Kernel Linux
O suporte inicial será implementado no Shim e no GRUB.
Até que o Kernel Linux incorpore metadados SBAT, ele será revogado apenas por certificado.
Com o tempo, o kernel assinado passará a incluir:
- Assinaturas específicas com EFI_SIGNATURE_DATA,
- Metadados SBAT separados,
- E políticas de verificação de lockdown e kexec, com base nesses números.
Metadados de revogação baseados em geração (.sbat section)
A seção .sbat de cada binário conterá:
- component_name
- component_generation
- vendor_name
- vendor_package_name
- vendor_version
- vendor_url
Esses dados serão usados para atualizar a variável UEFI SbatLevel, permitindo revogar componentes de forma granular conforme CVE(s) forem descobertos.
Exemplos reais já estão disponíveis para builds do GRUB em distribuições como Fedora e Debian, com diferentes combinações de produto, versão e geração.
Conclusão: SBAT – um futuro mais seguro e eficiente para o boot Linux
A proposta do SBAT pela Microsoft, em colaboração com a comunidade Linux, representa um avanço monumental para a segurança de inicialização e o ciclo de vida do UEFI Secure Boot. Ao substituir a ineficiente revogação por hash de imagem por um mecanismo baseado em números de geração, o SBAT promete maior eficiência, menos disrupção e uma proteção mais robusta contra vulnerabilidades críticas como o BootHole.
Essa inovação é crucial para garantir que o Linux continue a operar de forma segura e atualizada em PCs modernos, fortalecendo a confiança no open source e na interoperabilidade entre fornecedores.
Compreender as nuances do SBAT é vital para administradores de sistemas e desenvolvedores. Mantenha-se informado sobre a evolução do UEFI Secure Boot e as novas fronteiras da segurança Linux, acompanhando as análises aprofundadas do SempreUpdate!
