Pesquisadores da empresa de segurança de firmware Binarly encontraram seis novas falhas no U-Boot, um bootloader amplamente usado em dispositivos com Linux embarcado, incluindo controladores de gerenciamento de placa-mãe, ou BMCs, de servidores corporativos, equipamentos de rede, sistemas industriais, dispositivos de IoT e outros aparelhos.
Quatro dos bugs podem derrubar um dispositivo.
Os outros dois podem permitir que um invasor, ao inserir uma imagem maliciosa antes do bootloader, execute seu próprio código antes que o equipamento confirme se o software é legítimo.
Em cenários mais graves, isso abre caminho para ataques furtivos ao firmware, capazes de contornar proteções de segurança e instalar malware persistente.
Esse é o ponto central.
Um bootloader roda antes do sistema operacional, então uma falha nessa etapa pode comprometer tudo o que é carregado depois.
As seis falhas podem ser exploradas enquanto o U-Boot ainda lê uma imagem não confiável, antes de verificar a assinatura.
O que a Binarly encontrou
O U-Boot pode empacotar kernel, árvore de dispositivos, ramdisk e outros componentes de inicialização em um único formato, o FIT (Flattened Image Tree), e verifica a assinatura digital desse pacote antes de passar o controle adiante.
Esse mecanismo faz parte da Inicialização Verificada, que usa assinaturas criptográficas para garantir que apenas imagens de firmware e do sistema operacional assinadas por uma chave confiável sejam carregadas durante a partida.
A Binarly investigou pontos fracos nessa checagem e encontrou seis.
“Reconhecendo a natureza crítica desse componente, a equipe Binarly Research decidiu examinar com mais atenção a funcionalidade central do projeto U-Boot”, informou a empresa.
“A pesquisa revelou seis vulnerabilidades distintas, com impactos que vão de negação de serviço, ou DoS, à execução arbitrária de código durante a verificação de uma imagem não confiável.”
Segundo a empresa, a maior parte do código vulnerável está no U-Boot desde a versão v2013.07, ao longo de mais de 50 versões estáveis, e também aparece em muitos firmwares de fabricantes construídos sobre o U-Boot.
“As seis vulnerabilidades divulgadas são:
BRLY-2026-037: uma falha que pode fazer o U-Boot travar ao processar uma imagem de firmware maliciosa e, em certas condições, pode ser usada para execução arbitrária de código.
BRLY-2026-038: uma vulnerabilidade de corrupção de memória que pode permitir a execução arbitrária de código durante a verificação da assinatura do firmware.
BRLY-2026-039: uma vulnerabilidade de leitura fora dos limites que pode derrubar dispositivos ao forçar o U-Boot a ler além da imagem de firmware.
BRLY-2026-040: uma desreferência de ponteiro nulo que permite que imagens de firmware especialmente elaboradas travem o bootloader.
BRLY-2026-041: validação incorreta de dados de firmware armazenados externamente, o que pode fazer o U-Boot travar ao processar imagens maliciosas.
BRLY-2026-042: uma falha de recursão sem limite que pode esgotar a memória de pilha disponível e derrubar o bootloader.”
As falhas foram catalogadas como os avisos da Binarly BRLY-2026-037 a BRLY-2026-042.
Até o momento, nenhum identificador CVE foi atribuído.
Elas se dividem em dois grupos: duas que podem executar código e quatro que apenas causam travamento.
As duas primeiras são BRLY-2026-037 e BRLY-2026-038, ambas ligadas a um valor que não é validado.
O U-Boot chama fdt_get_name, uma busca na biblioteca de análise de árvore de dispositivos que ele utiliza, e, em uma imagem malformada, essa consulta retorna um ponteiro nulo e um comprimento negativo.
O U-Boot usa os dois sem verificar nenhum deles.
Uma das falhas leva o ponteiro nulo para uma cópia de memória que, em dispositivos em que o endereço zero está mapeado, se transforma em um estouro de buffer na pilha.
A outra usa o comprimento negativo em uma aritmética de ponteiros que recua até sobrescrever um endereço de retorno salvo.
Na combinação certa de memória, qualquer uma das duas pode entregar o controle ao código fornecido pelo invasor.
As outras quatro falhas apenas travam o bootloader.
BRLY-2026-039 e BRLY-2026-041 leem além do fim da imagem ao confiar em um tamanho ou deslocamento controlado pelo atacante.
BRLY-2026-040 desreferencia um ponteiro nulo devolvido sem validação por um formato de imagem mais antigo.
BRLY-2026-042 esgota a pilha, disparada por uma imagem profundamente aninhada que faz uma etapa inicial de validação chamar a si mesma até ficar sem recursos.
Se forem exploradas com sucesso, as falhas de execução arbitrária de código podem permitir que invasores executem instruções nas fases mais iniciais do processo de inicialização.
Como isso ocorre antes do carregamento do sistema operacional, os invasores podem desativar recursos de segurança do firmware, alterar o processo de boot, instalar malware persistente no firmware ou executar outras ações maliciosas com alto nível de acesso.
A Binarly publicou uma imagem de prova de conceito e os passos de reprodução para cada falha, demonstrando os problemas em compilações padrão do U-Boot.
Até o momento, não há relatos de exploração em ataques reais.
O tamanho do problema
No pior cenário, recuperar um dispositivo que não inicializa exige acesso físico e a regravação do chip de memória com uma imagem limpa.
Execução de código é ainda pior.
Código que roda tão cedo fica abaixo do sistema operacional, onde ferramentas de segurança comuns talvez não consigam enxergá-lo.
A Binarly afirma que esse tipo de atividade maliciosa seria difícil de detectar, já que ocorre antes da inicialização do sistema operacional.
O desafio para o atacante é a entrega.
Essas falhas só funcionam quando uma imagem maliciosa chega ao caminho de boot, o que normalmente exige acesso físico ou um ponto de apoio privilegiado.
E esse ponto de apoio nem sempre é local.
Em sistemas como BMCs, que suportam atualizações remotas de firmware, um invasor que já tenha comprometido a interface de gerenciamento pode enviar uma imagem de firmware especialmente criada para explorar as falhas.
Em um trabalho anterior sobre controladores de gerenciamento de servidores da Supermicro, o mesmo pesquisador da Binarly mostrou que um invasor com acesso remoto à interface de gerenciamento poderia abusar do próprio processo de atualização do dispositivo para gravar uma imagem maliciosa, sem tocar no hardware.
O que fazer
Ainda não há uma versão estável com a correção, então fornecedores e mantenedores de produtos baseados no U-Boot não devem esperar.
O ideal é incorporar agora as correções do código-fonte original, seguindo os links dos commits em cada aviso da Binarly, e acompanhar tudo pelo identificador do aviso, já que não existem CVEs por enquanto.
A Binarly informou as vulnerabilidades aos mantenedores do U-Boot e enviou patches para os seis problemas, que já foram aceitos no código principal do projeto.
No entanto, como o U-Boot é integrado ao firmware por fabricantes de hardware individualmente, as correções precisam primeiro ser incorporadas às atualizações de firmware desses fornecedores antes de chegarem aos clientes.
Dispositivos mais antigos ou sem suporte, que não recebem mais atualizações de firmware, talvez nunca sejam corrigidos.
O U-Boot incorporou os seis patches em junho, mas a versão de julho, v2026.07, já estava congelada desde abril e foi lançada sem eles.
A próxima versão, v2026.10, só deve sair em outubro.
Para o restante do mercado, o cenário é outro.
A maioria usa dispositivos fabricados por terceiros sobre U-Boot.
Nesses casos, a correção precisa chegar por meio de uma atualização de firmware do fabricante.
É isso que vale monitorar.
Essa checagem já falhou antes.
A mesma lógica de assinatura foi explorada meses antes por
CVE-2026-33243
, corrigida pelo U-Boot em abril.
O bootloader barebox, relacionado e que usa a mesma ferramenta de imagens, também foi afetado.
Naquele caso, uma propriedade destinada apenas a listar o que a assinatura cobre não era assinada, o que permitia que uma imagem adulterada substituísse partes que nunca haviam sido verificadas.
A função por trás das duas falhas mais graves aqui, fdt_get_name, vem da libfdt, a biblioteca de árvore de dispositivos achatada compartilhada pelo U-Boot, pelo kernel Linux, pelo barebox e por outros projetos.
O mesmo erro de retorno não verificado pode aparecer em qualquer lugar onde esse código seja usado.
O LogoFAIL, coberto pelo The Hacker News em 2023, foi um conjunto de falhas de análise de imagem em firmwares de PCs que permitia executar código durante a inicialização, antes de o Secure Boot verificar qualquer coisa, em praticamente todas as grandes marcas de computador.
A assinatura recebe toda a atenção, mas os bugs continuam aparecendo na infraestrutura que roda antes dela.
E, como o BootHole mostrou em 2020, quando uma falha no bootloader quebrou o Secure Boot em todo o ecossistema, escrever o patch é a parte fácil.
O difícil é levá-lo aos milhões de dispositivos que executam uma cópia do U-Boot de terceiros.
Publicidade
Conheça a Solyd One, e tenha acesso a todos os cursos de segurança ofensiva da Solyd, todas as certificações práticas, incluindo a SYCP, 2 CTFs anuais com prêmios de até 30 mil reais, dezenas de laboratórios realísticos, suporte, comunidade e muito mais. Saiba mais...