Seis vulnerabilidades em U-Boot poderiam executar código antes de verificar a assinatura e comprometer toda a cadeia de confiança

Pesquisadores da assinatura especializada em segurança de firmware Binarly descobriu seis vulnerabilidades em U-Boot, o carregador de arranque que atua como primeiro código executado em equipamentos tão diversos como roteadores domésticos, câmeras inteligentes e chips de gestão de centros de dados. A gravidade não vem apenas pela possibilidade de deixar uma equipe inservível: duas dessas falhas permitem executar código antes que a imagem assinada seja verificada, o que significa que um atacante poderia, em condições concretas, subverter toda a cadeia de confiança do dispositivo.

Tecnicamente, o problema concentra-se no manejo de FIT (Flattened Image Tree), o recipiente que U-Boot usa para agrupar kernel, árvore de dispositivo, ramdisk e outros componentes. Os seis erros são activados enquanto U-Boot ainda está a piscar uma imagem não confiável e antes de validar sua assinatura. Os dois mais críticos (BRLY-2026-037 e BRLY-2026-038, segundo os avisos de Binarly) derivam de uma chamada a fdt_get_name (procedente da biblioteca libfdt que compartilham U-Boot e o kernel Linux) que sobre uma imagem malformada devolve um ponteiro nulo e um comprimento negativo, valores que o código não verifica e que podem conduzir a corrupção de memória controlada pelo atacante.

Os outros erros saem do mesmo padrão: confiar em offsets e tamanhos fornecidos pela imagem, aceitar nós ou formatos antigos sem validação, ou permitir uma profundidade de aninhado que esgota a pilha. Alguns provocam simplesmente um bloqueio do carregador de arranque, mas um bloqueio ainda pode deixar uma equipe sem arrancar e exigir intervenção física para reflectir a memória.

Essas vulnerabilidades não são novas em termos de perspectiva: Binarly aponta que grande parte desse código vulnerável existe em U-Boot desde 2013 e permanece em dezenas de ramos estáveis e em firmwares de múltiplos fornecedores. Além disso, a falha sublinha uma lição repetida em segurança de arranque: a assinatura é eficaz somente se todo o código e os metadados que precedem são tratados de forma segura. Incidentes anteriores como o BootHole e outras falhas em parsers de imagens (p. ex. LogoFAIL) mostraram como a lógica prévia à verificação pode se tornar a rota de ataque.

Binarly publicou testes de conceito e passos de reprodução contra builds padrão de U-Boot, e os adesivos fundiram-se na árvore upstream em junho. No entanto, a versão de julho de U-Boot (v2026.07) se congelou antes de incluí-los e a próxima release planejada para outubro, v2026.10, chega tarde demais para muitos usuários. Ainda não há CVE atribuído a estas seis falhas, portanto, é crucial segui-las por suas referências BRLY-2026-037 a BRLY-2026-042 e aplicar as correções upstream quanto antes.

Para fabricantes e mantenedores de produtos baseados em U-Boot, a recomendação é imediata: integrar os commits corrigidos do repositório upstream, testar firmemente nos fluxos de arranque de suas plataformas e preparar atualizações de firmware para distribuição. Como o adesivo já existe em U-Boot, mas não aparecerá na release estável imediata, não esperar o próximo tarball da comunidade é uma decisão sensata.

Para administradores e usuários finais, a proteção requer vigilância e mitigação pragmáticas: monitorar avisos de segurança do fornecedor para obter atualizações de firmware, segmentar e restringir o acesso a interfaces de gestão remota (BMC/iDRAC/iLO e similares) e minimizar a exposição de processos de atualização automáticos a redes não confiáveis. Em casos em que o fornecedor não ofereça adesivos, convém avaliar medidas temporárias como desativar atualizações remotas ou isolar o dispositivo até que haja uma correção oficial.

É importante sublinhar a dificuldade real que segue à publicação do adesivo: atualizar milhões de dispositivos repartidos por múltiplos fornecedores é o verdadeiro pescoço de garrafa. Mesmo quando a comunidade corrige o código, o adesivo deve ser devidamente testado e implantado por cada fabricante, e muitas vezes isso requer tempo e recursos que nem todos os atores estão dispostos a investir com a urgência necessária.

Em termos de detecção, estas falhas são complexas: a execução precoce pode ficar fora do alcance de ferramentas habituais de segurança do sistema operacional. Por isso, a defesa deve priorizar a redução de vetores de entrega: proteger processos de atualização, endurecer acessos de gestão remota e aplicar controles de integridade e recuperação de firmware (incluindo a necessidade de acesso físico para recuperação quando possível).

Aqueles que querem aprofundar U-Boot e seu ecossistema podem consultar a documentação oficial em https://u-boot.org/ e a especificação / documentação sobre device trees na árvore do kernel https://www.kernel.org/doc/html/latest/devicetree/. Para contexto histórico sobre por que as falhas em carregadores de arranque são perigosas, a pesquisa e a análise do BootHole oferecem um bom referente: https://www.eclypsium.com/blog/2020/boot-hole/.

Em resumo, essas seis falhas voltam a apontar uma regra básica: a segurança do arranque é tão forte quanto o seu elo mais fraco na fase anterior à assinatura. Fornecedores, integradores e administradores já devem agir para aplicar as correções upstream, acender o alerta sobre a distribuição de firmware e reduzir as vias através das quais uma imagem maliciosa poderia chegar ao processo de arranque.