📰 Informação fresquinha chegando para você!
Confira agora e compartilhe com seus amigos!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Pesquisadores da empresa de segurança de firmware Binarly encontraram seis novas falhas no U-Boot, o pequeno programa que inicializa hardware tão variado quanto roteadores domésticos, câmeras inteligentes e chips de gerenciamento dentro de servidores de data center.
Quatro dos bugs podem travar um dispositivo. Os outros dois poderiam permitir que um invasor que colocasse uma imagem maliciosa na frente do bootloader executasse seu próprio código, antes que o dispositivo confirmasse que o software é genuíno.
Essa última parte é o ponto. Um bootloader é executado antes do sistema operacional, portanto, uma falha aqui pode prejudicar tudo o que for carregado depois dele. Todos os seis bugs foram detectados enquanto o U-Boot ainda estava lendo uma imagem não confiável, antes de verificar a assinatura.
O que Binarly encontrou
O U-Boot pode agrupar um kernel, árvore de dispositivos, ramdisk e outros componentes de inicialização em um pacote, um FIT (Flattened Image Tree), e verifica a assinatura digital desse pacote antes de entregar o controle.
Binarly procurou pontos fracos nesse cheque e encontrou seis. A maior parte do código vulnerável está no U-Boot desde a v2013.07, diz Binarly, em mais de 50 versões estáveis, e também reside em muitos firmwares de fornecedores criados com base no U-Boot.
Os bugs são rastreados como avisos binários BRLY-2026-037 até BRLY-2026-042. Nenhum identificador CVE foi atribuído ainda. Eles se enquadram em dois grupos: dois que podem executar código e quatro que apenas travam.
Os dois são BRLY-2026-037 e BRLY-2026-038, e ambos rastreiam um valor não verificado. O U-Boot chama fdt_get_name, uma pesquisa na biblioteca de análise de árvore de dispositivos que ele empresta e, em uma imagem malformada, essa pesquisa retorna um ponteiro nulo e um comprimento negativo. O U-Boot usa ambos sem verificar nenhum deles.
Um bug segue o ponteiro nulo para uma cópia de memória que, em dispositivos onde o endereço zero está mapeado, se torna um estouro de buffer de pilha. O outro alimenta o comprimento negativo na aritmética do ponteiro que retrocede até substituir um endereço de retorno salvo. No layout de memória correto, qualquer um pode controlar manualmente o código fornecido pelo invasor.
Os outros quatro travam apenas o bootloader. BRLY-2026-039 e BRLY-2026-041 leem além do final da imagem confiando em um tamanho ou deslocamento que o invasor controla. BRLY-2026-040 desreferencia um ponteiro nulo que um formato de imagem mais antigo devolve sem verificação. BRLY-2026-042 esgota a pilha, desencadeada por uma imagem profundamente aninhada que aciona uma etapa de validação inicial para chamar a si mesma até que ela acabe.
A Binarly publicou uma imagem de prova de conceito e etapas de reprodução para cada falha e as demonstrou em versões padrão do U-Boot. Nenhuma exploração em ataques reais foi relatada.
Dos seis, os dois bugs de corrupção de memória são os que devem ser priorizados: uma falha pode deixar um dispositivo offline, mas a execução do código na inicialização pode subverter toda a sua cadeia de confiança.
Quão ruim fica
Na pior das hipóteses, recuperar um dispositivo que não inicializa significa acesso físico e atualizar seu chip de memória com uma imagem limpa. A execução do código é pior. O código executado tão cedo fica abaixo do sistema operacional, onde as ferramentas de segurança comuns podem não detectá-lo.
O problema para um invasor é a entrega: esses bugs só aparecem quando uma imagem maliciosa atinge o caminho de inicialização, que geralmente requer acesso físico ou uma posição privilegiada. Essa posição nem sempre é local.
Em trabalhos anteriores 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 exibir uma imagem maliciosa, sem tocar no hardware.
O que fazer
Ainda não há uma versão estável com a correção, portanto, os fornecedores e mantenedores de produtos baseados em U-Boot não devem esperar: extraia as correções upstream agora, seguindo os links de commit em cada aviso Binarly, e rastreie-os por ID de aviso, já que não existem CVEs.
O U-Boot fundiu os seis patches em junho, mas a versão de julho (v2026.07) já havia congelado em abril, então foi enviado sem eles; a próxima versão, v2026.10, só será lançada em outubro.
Todos os outros executam um dispositivo que outra pessoa construiu no U-Boot. Para eles, a correção deve chegar como uma atualização de firmware do fornecedor do produto. É isso que você deve observar.
Esta verificação exata falhou antes. A mesma lógica de assinatura foi atingida meses antes pelo CVE-2026-33243, que o U-Boot corrigiu em abril; o bootloader barebox relacionado, que usa as mesmas ferramentas de imagem, também foi atingido.
Nesse bug, uma propriedade destinada apenas a listar o que a assinatura cobre não estava assinada, de modo que uma imagem adulterada poderia trocar partes que nunca foram verificadas. O ajudante por trás dos dois piores bugs aqui, fdt_get_name, vem da libfdt, a biblioteca de árvore de dispositivos achatada que o U-Boot compartilha com o kernel do Linux, barebox e outros. O mesmo erro de retorno não verificado pode surgir em qualquer lugar em que o código seja usado.
LogoFAIL, abordado pela THN em 2023, era um conjunto de bugs de análise de imagem no firmware do PC que permitiam ataques
Quatro dos bugs podem travar um dispositivo. Os outros dois poderiam permitir que um invasor que colocasse uma imagem maliciosa na frente do bootloader executasse seu próprio código, antes que o dispositivo confirmasse que o software é genuíno.
Essa última parte é o ponto. Um bootloader é executado antes do sistema operacional, portanto, uma falha aqui pode prejudicar tudo o que for carregado depois dele. Todos os seis bugs foram detectados enquanto o U-Boot ainda estava lendo uma imagem não confiável, antes de verificar a assinatura.
O que Binarly encontrou
O U-Boot pode agrupar um kernel, árvore de dispositivos, ramdisk e outros componentes de inicialização em um pacote, um FIT (Flattened Image Tree), e verifica a assinatura digital desse pacote antes de entregar o controle.
Binarly procurou pontos fracos nesse cheque e encontrou seis. A maior parte do código vulnerável está no U-Boot desde a v2013.07, diz Binarly, em mais de 50 versões estáveis, e também reside em muitos firmwares de fornecedores criados com base no U-Boot.
Os bugs são rastreados como avisos binários BRLY-2026-037 até BRLY-2026-042. Nenhum identificador CVE foi atribuído ainda. Eles se enquadram em dois grupos: dois que podem executar código e quatro que apenas travam.
Os dois são BRLY-2026-037 e BRLY-2026-038, e ambos rastreiam um valor não verificado. O U-Boot chama fdt_get_name, uma pesquisa na biblioteca de análise de árvore de dispositivos que ele empresta e, em uma imagem malformada, essa pesquisa retorna um ponteiro nulo e um comprimento negativo. O U-Boot usa ambos sem verificar nenhum deles.
Um bug segue o ponteiro nulo para uma cópia de memória que, em dispositivos onde o endereço zero está mapeado, se torna um estouro de buffer de pilha. O outro alimenta o comprimento negativo na aritmética do ponteiro que retrocede até substituir um endereço de retorno salvo. No layout de memória correto, qualquer um pode controlar manualmente o código fornecido pelo invasor.
Os outros quatro travam apenas o bootloader. BRLY-2026-039 e BRLY-2026-041 leem além do final da imagem confiando em um tamanho ou deslocamento que o invasor controla. BRLY-2026-040 desreferencia um ponteiro nulo que um formato de imagem mais antigo devolve sem verificação. BRLY-2026-042 esgota a pilha, desencadeada por uma imagem profundamente aninhada que aciona uma etapa de validação inicial para chamar a si mesma até que ela acabe.
A Binarly publicou uma imagem de prova de conceito e etapas de reprodução para cada falha e as demonstrou em versões padrão do U-Boot. Nenhuma exploração em ataques reais foi relatada.
Dos seis, os dois bugs de corrupção de memória são os que devem ser priorizados: uma falha pode deixar um dispositivo offline, mas a execução do código na inicialização pode subverter toda a sua cadeia de confiança.
Quão ruim fica
Na pior das hipóteses, recuperar um dispositivo que não inicializa significa acesso físico e atualizar seu chip de memória com uma imagem limpa. A execução do código é pior. O código executado tão cedo fica abaixo do sistema operacional, onde as ferramentas de segurança comuns podem não detectá-lo.
O problema para um invasor é a entrega: esses bugs só aparecem quando uma imagem maliciosa atinge o caminho de inicialização, que geralmente requer acesso físico ou uma posição privilegiada. Essa posição nem sempre é local.
Em trabalhos anteriores 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 exibir uma imagem maliciosa, sem tocar no hardware.
O que fazer
Ainda não há uma versão estável com a correção, portanto, os fornecedores e mantenedores de produtos baseados em U-Boot não devem esperar: extraia as correções upstream agora, seguindo os links de commit em cada aviso Binarly, e rastreie-os por ID de aviso, já que não existem CVEs.
O U-Boot fundiu os seis patches em junho, mas a versão de julho (v2026.07) já havia congelado em abril, então foi enviado sem eles; a próxima versão, v2026.10, só será lançada em outubro.
Todos os outros executam um dispositivo que outra pessoa construiu no U-Boot. Para eles, a correção deve chegar como uma atualização de firmware do fornecedor do produto. É isso que você deve observar.
Esta verificação exata falhou antes. A mesma lógica de assinatura foi atingida meses antes pelo CVE-2026-33243, que o U-Boot corrigiu em abril; o bootloader barebox relacionado, que usa as mesmas ferramentas de imagem, também foi atingido.
Nesse bug, uma propriedade destinada apenas a listar o que a assinatura cobre não estava assinada, de modo que uma imagem adulterada poderia trocar partes que nunca foram verificadas. O ajudante por trás dos dois piores bugs aqui, fdt_get_name, vem da libfdt, a biblioteca de árvore de dispositivos achatada que o U-Boot compartilha com o kernel do Linux, barebox e outros. O mesmo erro de retorno não verificado pode surgir em qualquer lugar em que o código seja usado.
LogoFAIL, abordado pela THN em 2023, era um conjunto de bugs de análise de imagem no firmware do PC que permitiam ataques
Fonte: https://thehackernews.com
#samirnews #samir #news #boletimtec #seis #novas #falhas #no #uboot #podem #permitir #que #imagens #maliciosas #travem #dispositivos #ou #executem #código #na #inicialização
🔔 Siga-nos para não perder nenhuma atualização!
Postar um comentário