Definição de SBAT (Secure Boot Advanced Targeting)
- Quando o UEFI Secure Boot foi definido pela primeira vez, todos os envolvidos foram um tanto ingênuos
- O modelo básico de segurança do Secure Boot é que todo código executado em um ambiente de privilégio no nível do kernel deve ser verificado antes da execução
- Isso inclui uma forma de revogar componentes assinados quando vulnerabilidades são descobertas
- Porém, como todas as distribuições Linux que funcionam no ecossistema do Secure Boot geram seus próprios binários de bootloader, quando uma vulnerabilidade é identificada há muitos binários que precisam ser revogados
- Como o espaço para armazenar hashes é limitado, o SBAT foi desenvolvido
Como o SBAT funciona
- Todos os componentes importantes da cadeia de boot declaram uma geração de segurança incluída no binário assinado
- Quando uma vulnerabilidade é identificada e corrigida, essa geração é incrementada
- Uma atualização pode definir a geração mínima
- Um componente de boot verifica o próximo item da cadeia e compara seu nome e número de geração com o que está armazenado em uma variável de firmware para decidir se deve executá-lo
- Em vez de revogar muitos hashes individuais, é possível enviar uma única atualização dizendo que versões do
grub com geração de segurança inferior a um determinado número não são confiáveis
Causa do problema recente
- A Microsoft distribuiu uma atualização do Windows para deixar de confiar em versões do
grub com geração de segurança abaixo de um certo nível
- Isso aconteceu porque essas versões do
grub tinham vulnerabilidades reais de segurança que poderiam comprometer a cadeia de Secure Boot do Windows
- O problema é que algumas distribuições Linux ainda não haviam disponibilizado novas versões do
grub com a geração de segurança atualizada
- A intenção da Microsoft era aplicar a atualização do SBAT apenas em sistemas com somente Windows, mas isso não funcionou como planejado
Resumo
- A Microsoft enviou uma atualização do Windows para impedir que versões vulneráveis do
grub fossem usadas para atacar o Windows
- Essa atualização deveria não se aplicar a sistemas com dual boot, mas isso foi ignorado
- Algumas distribuições Linux não atualizaram o código do
grub nem a geração de segurança do SBAT
- Como resultado, alguns usuários ficaram sem conseguir inicializar o sistema
Quem deve ser responsabilizado
- A Microsoft deveria ter feito mais testes para identificar corretamente configurações com dual boot
- Mas as distribuições que fornecem bootloaders assinados também precisam atualizá-los e atualizar a geração de segurança
- Isso porque elas podem fornecer um vetor que pode ser usado para atacar outros sistemas operacionais
Conclusão
- É lamentável que os usuários finais, que de repente ficaram sem conseguir inicializar o sistema operacional que queriam, tenham sido as vítimas
- Isso nunca deveria acontecer
- Embora eu ache que o UEFI Secure Boot não pareça trazer benefícios para a maioria dos usuários finais, ninguém quer descobrir depois do fato algo de que precisava, então entendo a decisão da Microsoft de deixá-lo ativado por padrão
- Exceto pela tentativa fracassada de evitar a atualização em sistemas com dual boot, entendo a escolha da Microsoft
Opinião do GN⁺
- Este caso mostra como é difícil equilibrar segurança e experiência do usuário
- Tanto a Microsoft quanto as distribuições Linux estão tentando proteger os usuários da melhor forma possível, mas a experiência do usuário pode acabar sendo sacrificada nesse processo
- Usuários que utilizam sistemas com dual boot têm maior probabilidade de enfrentar esse tipo de problema
- Portanto, para quem usa dual boot, é importante manter ambos os sistemas operacionais nas versões mais recentes e atualizá-los regularmente
- No longo prazo, parece necessário haver melhor colaboração e coordenação entre as comunidades Linux e Windows
1 comentários
Opiniões do Hacker News
suspend-to-hiberfile.syse com atualizações quebrando o grub