Matthew Garrett, um renomado desenvolvedor do núcleo Linux que recebeu um prêmio da Free Software Foundation por suas contribuições ao software livre, explicou sobre a mecânica do SBAT (Secure Boot Advanced Targeting), criada para bloquear vulnerabilidades no carregador sem revogar a assinatura digital, e também sobre seu papel no recente incidente relacionado a uma atualização do Windows, que resultou na interrupção da inicialização de algumas distribuições Linux instaladas ao lado do Windows em sistemas com UEFI Secure Boot ativado. Em resumo, a responsabilidade é tanto da Microsoft, que não testou adequadamente a atualização e a aplicou em sistemas para os quais não deveria ter sido aplicada, quanto dos desenvolvedores de algumas distribuições Linux que não atualizaram o carregador GRUB e a versão do SBAT quando vulnerabilidades foram descobertas no GRUB.
Abaixo está a tradução da observação de Garrett:
Quando a especificação do UEFI Secure Boot estava sendo desenvolvida, todos os participantes estavam, digamos, um pouco ingênuos. O modelo de segurança do Secure Boot estabelece que todo o código que é executado em um ambiente privilegiado a nível de núcleo deve ser verificado antes de ser executado — o firmware verifica o carregador, o carregador verifica o núcleo, o núcleo verifica qualquer código adicional carregado em tempo de execução, e agora temos um ambiente confiável para impor qualquer outra política de segurança que desejamos. É óbvio que as pessoas podem cometer erros, mas a especificação previu uma maneira de revogar componentes assinados que se mostraram não confiáveis: basta adicionar o hash do código não confiável à variável e, em seguida, recusar-se a carregar qualquer coisa com esse hash, mesmo que esteja assinada por uma chave confiável.
Infelizmente, como se descobriu, o problema está na escala. Cada distribuição Linux que opera dentro do ecossistema Secure Boot gera seus próprios arquivos binários de inicialização, e cada um deles tem seu próprio hash. Se uma vulnerabilidade for encontrada no código-fonte desse inicializador, será necessário revogar um grande número de arquivos binários diferentes. E o espaço de memória disponível para armazenar a variável que contém todos esses hashes é limitado. Simplesmente não haverá espaço suficiente para adicionar um novo conjunto de hashes sempre que se descobrir que o GRUB (o inicializador, originalmente escrito em uma época em que a proteção de inicialização não era praticada e que possui vários analisadores separados de imagens img, assim como um analisador de fontes) tem mais um mecanismo para que um atacante possa forçá-lo a executar código arbitrário, portanto, foi necessária uma outra solução.
Essa solução foi o SBAT. O conceito geral do SBAT é bastante simples. Cada componente importante na cadeia de inicialização declara uma geração de segurança, que é incorporada ao arquivo binário assinado. Quando uma vulnerabilidade é descoberta e corrigida, essa geração é aumentada. Então, uma atualização pode ser lançada, definindo a geração mínima – os componentes de inicialização olharão para o próximo elemento na cadeia, compararão seu nome e número de geração com aqueles que estão armazenados na variável de firmware e decidirão se o executam ou não, com base nisso. Em vez de revogar uma grande quantidade de hashes separados, pode-se lançar uma única atualização que simplesmente diz: "Qualquer versão do GRUB com a geração de segurança abaixo desse número é considerada não confiável."
Por que isso se tornou relevante de repente? O SBAT foi desenvolvido em conjunto pela comunidade Linux e pela Microsoft, e a Microsoft decidiu lançar uma atualização para o Windows que instruía os sistemas a não confiarem em versões do GRUB com geração de segurança abaixo de um determinado nível. Isso foi feito porque essas versões do GRUB tinham vulnerabilidades reais de segurança que permitiram que invasores comprometesse a cadeia de inicialização segura do Windows, e vimos exemplos reais de malware que queria fazer isso (o Black Lotus explorou uma vulnerabilidade no inicializador do Windows, mas a vulnerabilidade no GRUB era igualmente eficaz). Se olharmos para isso puramente do ponto de vista da segurança, é um desejo plenamente válido.
Agora, quanto à mensagem "Algo deu muito errado" e à impossibilidade de inicialização devido a essa atualização. Ela é gerada pelo shim, e não por algum código da Microsoft. O shim leva em consideração as atualizações SBAT e, para não comprometer os princípios de segurança aceitos por outros carregadores no sistema, embora a Microsoft tenha lançado a atualização SBAT, é o carregador do Linux que, como resultado, se recusa a iniciar versões antigas do GRUB. Tudo funciona como deveria.
O problema que as pessoas enfrentaram é que várias distribuições do Linux não lançaram versões do GRUB com a nova geração de segurança, e, portanto, essas versões do GRUB são consideradas inseguras (é importante notar que o GRUB é assinado pelas próprias distribuições, e não pela Microsoft, então não há atrasos impostos externamente). A intenção da Microsoft era que a atualização do Windows aplicasse a atualização SBAT apenas a sistemas que operam exclusivamente com Windows, e qualquer instalação com inicialização dupla continuaria vulnerável a ataques até que a distribuição instalada atualizasse o GRUB e a nova geração SBAT. Infelizmente, como agora está evidente, isso não funcionou como deveria, e pelo menos alguns sistemas com inicialização dupla aplicaram a atualização, enquanto o shim dessa distribuição se recusou a carregar o GRUB dessa distribuição.
Qual é a conclusão? A Microsoft (por razões compreensíveis) não queria que o Windows fosse atacado por uma versão vulnerável do GRUB, que poderia ser enganada para executar código arbitrário e, em seguida, injetar um bootkit no kernel do Windows durante a inicialização. A Microsoft fez isso lançando uma atualização do Windows que atualizou a variável SBAT, indicando que versões vulneráveis do GRUB não deveriam ser carregadas nesses sistemas. O carregador de primeiro estágio fornecido pela distribuição leu essa variável, leu a seção SBAT da cópia instalada do GRUB, percebeu que havia um conflito e se recusou a carregar o grub com a mensagem "Algo deu muito errado". Esta atualização não deveria ter sido aplicada a sistemas com inicialização dupla, mas ainda assim foi.
Em resumo:
1) A Microsoft aplicou a atualização a sistemas para os quais ela não deveria ter sido aplicada.
2) Algumas distribuições Linux não atualizaram o carregador GRUB e a geração de segurança SBAT, quando vulnerabilidades foram descobertas no GRUB.
Como resultado, algumas pessoas não conseguem inicializar seus sistemas. Acredito que há muitos culpados aqui. A Microsoft deveria ter realizado mais testes para garantir que as instalações de dual boot possam ser identificadas corretamente. Mas as distribuições que fornecem carregadores assinados também devem garantir que os atualizem e façam a atualização de segurança para se adequar, porque, caso contrário, elas fornecem um vetor de ataque que pode ser usado para invadir outros sistemas operacionais, e isso é uma espécie de violação do contrato social em torno de tudo isso.
Infelizmente, as vítimas aqui são principalmente os usuários finais, que se deparam com o fato de que o sistema de repente se recusa a inicializar o sistema operacional que eles desejam carregar. Isso nunca deveria ter acontecido. Não acho que uma pesquisa com os usuários finais sobre se eles desejam atualizações de sistema de inicialização segura levará a um bom resultado, e embora eu tenda a achar que a inicialização segura UEFI não traz benefícios para a maioria dos usuários finais, também é uma coisa que você não quer descobrir após incidentes como esse, então simpatizo com o fato de que ela esteja habilitada por padrão, por isso apoio que ela esteja habilitada por padrão, e compartilho a escolha da Microsoft, exceto pela tentativa malsucedida de evitar atualizações em sistemas com dual boot.
De qualquer forma, estive muito envolvido na implementação desse mecanismo para Linux em 2012 e escrevi o primeiro protótipo do Shim (que agora é um carregador significativamente melhor, suportado por um público mais amplo, e que não toquei há vários anos), então, se você quiser culpar uma única pessoa, sinta-se à vontade para me culpar. Isso não deveria ter acontecido, e se você não for a Microsoft ou uma distribuição Linux, então não é sua culpa. Peço desculpas.
Fonte: opennet.ru
