CVE-2023-40547 – evite confiar incorretamente em cabeçalhos HTTP

Artigo original ↗ Discussão no Hacker News ↗

Uma vulnerabilidade crítica (CVE-2023-40547) no bootloader shim usado para Secure Boot no Linux permite gravações fora dos limites quando ele confia nos cabeçalhos HTTP `Content-Length`, potencialmente permitindo que atacantes contornem o Secure Boot em cenários de network boot e em certos cenários locais ou de MITM. Comentadores explicam como o shim se encaixa na cadeia do Secure Boot, por que o tratamento de HTTP/HTTPS no nível de firmware é complicado e por que esse bug é grave apesar de aparecer apenas em um caminho menos comum de HTTP boot. A thread também revisita preocupações de longa data sobre o controle da Microsoft sobre chaves de assinatura UEFI, os requisitos anti‑tivoização da GPLv3 e se o Secure Boot realmente protege os usuários ou apenas impõe controle do fornecedor.

Vulnerabilidade e contexto

  • O bug está no código de boot HTTP do shim: ele aloca um buffer com base no cabeçalho Content-Length, mas copia com base no tamanho real do corpo recebido, permitindo uma gravação fora dos limites se o cabeçalho mentir.
  • Isso existe em builds do shim que incluem suporte a HTTP boot; o shim é usado principalmente como um carregador Secure Boot assinado pela Microsoft que depois impõe sua própria política via Machine Owner Keys (MOK).
  • Manchetes anteriores sugerindo “todo bootloader Linux” foram corrigidas: trata-se de um bug do shim, introduzido há cerca de 8 anos.

Superfície de ataque e gravidade

  • Não se limita ao HTTP boot explícito:
    • Local: malware com privilégios pode sobrescrever a EFI System Partition ou variáveis EFI e forçar HTTP boot ou fazer chain shim→GRUB2→shim via HTTP.
    • Rede adjacente: PXE boot mais MITM pode ser encadeado para carregar o shim via HTTP.
    • Remoto: MITM no HTTP boot contra uma vítima que use HTTP boot.
  • Alguns argumentam que, uma vez que um atacante pode modificar variáveis EFI/ESP, outros ataques (por exemplo, adicionar MOKs, usar binários assinados mais antigos) já seriam possíveis; outros respondem que o objetivo do Secure Boot é justamente resistir a esse tipo de adulteração.
  • Há discordância sobre a classificação “Critical”: alguns veem isso como defesa em profundidade essencial, outros acham que é menos significativo se o servidor ou o sistema local já estiverem fortemente comprometidos.

HTTP vs HTTPS e detalhes de implementação

  • HTTPS não impede servidores maliciosos; ele principalmente bloqueia MITM.
  • Vários comentaristas observam que o código de UEFI/boot pode pular a validação adequada de certificados HTTPS (tamanho da CA store, complexidades de atualização e revogação, desvio de horário), tornando MITM realista mesmo em HTTPS.
  • Debate sobre a semântica de HTTP: em HTTP/1.1, Content-Length deveria ser a autoridade; se uma implementação em vez disso confiar em uma medição separada de “bodyLength”, ambas precisam ser reconciliadas cuidadosamente — essa divergência levou ao bug.

Shim, Secure Boot, MOK e revogação

  • O uso típico é shim → GRUB → kernel no disco local; HTTP boot é nichado, mas existe.
  • O shim verifica o binário da próxima etapa contra sua própria lista MOK; a revogação do Secure Boot via UEFI DBX pode invalidar binários vulneráveis do shim, mas muitos sistemas provavelmente nunca atualizam o DBX.
  • Measured boot e TPM podem, em princípio, vincular chaves de descriptografia do disco a componentes específicos do boot, mas isso é visto como complexo e raramente usado por usuários típicos.

GPLv3, anti‑tivoization e política de assinatura da Microsoft

  • Grande subthread sobre por que a Microsoft evita assinar bootloaders GPLv3 como o GRUB:
    • A cláusula de “Installation Information” da GPLv3 é citada: distribuidores de dispositivos com componentes GPLv3 devem fornecer quaisquer métodos/chaves de autorização necessários para os usuários instalarem e executarem versões modificadas nesse dispositivo.
    • Alguns inicialmente duvidam que isso se aplique a chaves de assinatura, mas depois concedem que a linguagem (“authorization keys”) junto com comentários da FSF sobre anti‑tivoization apoia essa interpretação.
    • Outros argumentam que permitir que os usuários registrem suas próprias chaves (em vez de fornecer chaves privadas do fornecedor) deveria satisfazer a licença, e observam que implementações ruins de Secure Boot que bloqueiam chaves do usuário são o verdadeiro problema.
    • Há debate sobre se assinaturas têm alguma relevância para copyright e se simplesmente assinar um binário (sem distribuí-lo) pode disparar obrigações da GPL; as opiniões divergem, e o status legal continua descrito como incerto.
  • O shim é licenciado sob MIT para contornar restrições da GPLv3, permitindo que seja assinado pela Microsoft enquanto aplica sua própria política de confiança (MOK).

Visões sobre Secure Boot e o ecossistema

  • Alguns veem Secure Boot como defesa em profundidade válida, especialmente contra ataques “evil maid” em ESPs não criptografadas, e argumentam que os fornecedores devem permitir controle do usuário sobre as chaves.
  • Outros são fortemente críticos:
    • Alegam que o Secure Boot principalmente consolida o controle do fornecedor (especialmente a chave padrão da Microsoft) e se assemelha mais a DRM do que a segurança do usuário.
    • Citam dispositivos em que o Secure Boot não pode ser desativado ou as chaves do usuário não podem ser adicionadas, e em que ativá-lo causa problemas de usabilidade (por exemplo, hibernação, avisos “assustadores”, atrito com Linux).
    • Preocupam-se com a plataforma PC caminhando para um jardim murado, comparando isso a problemas antitruste anteriores.

Boot de rede e escolhas de design

  • HTTP/PXE boot são descritos por vários como “pesadelos de segurança” ou pelo menos altamente arriscados, embora outros observem que são úteis para testes de laboratório e provisionamento.
  • Alguns questionam por que o shim implementa diretamente HTTP boot em vez de delegar a um binário EFI separado, assinado com MOK.
  • Há críticas de que um bug tão óbvio de confiança em cabeçalho não deveria ter passado pela revisão de código, com comentários comparando-o a um erro de iniciante, além de observações laterais sobre pequenas limpezas (por exemplo, correções de typo) no patch.