📰 Informação fresquinha chegando para você!
Não deixe essa passar: clique e saiba tudo!
Apoie esse projeto de divulgacao de noticias! Clique aqui
Foram descobertas seis vulnerabilidades no amplamente utilizado bootloader U-Boot que podem permitir que invasores executem código malicioso durante a inicialização do dispositivo, potencialmente permitindo ataques furtivos de firmware que comprometem as proteções de segurança e instalam malware persistente.
U-Boot é um dos bootloaders de código aberto mais usados no mundo e é encontrado em muitos dispositivos Linux embarcados, incluindo Baseboard Management Controllers (BMCs) de servidores corporativos, equipamentos de rede, sistemas industriais, dispositivos IoT e outros dispositivos.
Como o U-Boot é responsável por carregar o sistema operacional, as vulnerabilidades no bootloader podem permitir que invasores comprometam um dispositivo antes que o sistema operacional e seu software de segurança tenham a chance de iniciar.
Um de seus recursos de segurança, conhecido como inicialização verificada, usa assinaturas criptográficas para garantir que apenas imagens de firmware e sistema operacional assinadas por uma chave confiável sejam carregadas durante a inicialização.
Em um relatório publicado esta semana, a empresa de segurança de firmware Binarly divulgou seis vulnerabilidades no código de verificação de assinatura FIT (Flattened Image Tree) do U-Boot.
"Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely," explains Binarly.
“Esta pesquisa revelou seis vulnerabilidades distintas, variando em impacto desde negação de serviço (DoS) até execução arbitrária de código durante a verificação de uma imagem não confiável.”
Segundo os pesquisadores, duas das falhas podem levar à execução arbitrária de códigos durante a verificação do firmware, enquanto as quatro restantes podem ser exploradas para travar dispositivos vulneráveis.
Como essas falhas afetam o código de validação de imagens de firmware antes do sistema operacional ser iniciado, se um invasor conseguir explorar esse processo, ele poderá executar código malicioso antes do carregamento do sistema operacional.
As seis vulnerabilidades divulgadas são:
BRLY-2026-037: Uma falha que pode fazer com que o U-Boot trave ao processar uma imagem de firmware maliciosa e, sob 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 que invasores executem código arbitrário durante a verificação de assinatura de firmware.
BRLY-2026-039: Uma vulnerabilidade de leitura fora dos limites que pode travar dispositivos, forçando o U-Boot a ler além da imagem do firmware.
BRLY-2026-040: Uma desreferência de ponteiro nulo que permite que imagens de firmware especialmente criadas travem o bootloader.
BRLY-2026-041: Validação inadequada de dados de firmware armazenados externamente que pode causar falha no U-Boot ao processar imagens de firmware maliciosas.
BRLY-2026-042: Uma falha de recursão ilimitada que pode esgotar a memória disponÃvel da pilha e travar o bootloader.
De acordo com a Binarly, a maior parte do código vulnerável existe desde a versão 2013.07 do U-Boot, fazendo com que as falhas afetem potencialmente mais de 50 versões do projeto, bem como fornecedores que utilizaram o código vulnerável em seu próprio firmware.
“Isso significa que elas afetam potencialmente mais de 50 versões estáveis do projeto U-Boot. Contando com muitos forks de fornecedores downstream, essas vulnerabilidades têm um impacto significativo na indústria”, explica Binarly.
Se exploradas com sucesso, as vulnerabilidades de execução arbitrária de código poderão permitir que invasores executem código durante os primeiros estágios do processo de inicialização.
Como isso ocorre antes do carregamento do sistema operacional, os invasores podem desabilitar os recursos de segurança do firmware, modificar o processo de inicialização, instalar malware de firmware persistente ou realizar outras ações maliciosas com altos nÃveis de acesso.
Binarly diz que os maliciosos seriam difÃceis de detectar porque são executados antes do sistema operacional ser iniciado.
Binarly diz que a exploração dessas vulnerabilidades nem sempre requer acesso fÃsico. Em sistemas como BMCs que suportam atualizações remotas de firmware, um invasor que já tenha comprometido a interface de gerenciamento poderá fazer upload de uma imagem de firmware especialmente criada para explorar as falhas.
Binarly relatou as vulnerabilidades aos mantenedores do U-Boot e enviou patches para todos os seis problemas, que desde então foram aceitos na base de código upstream do projeto.
However, because U-Boot is integrated into firmware by individual hardware manufacturers, the fixes must first be incorporated into vendors' firmware updates before they can be distributed to customers.
Dispositivos mais antigos ou sem suporte que não recebem mais atualizações de firmware talvez nunca recebam patches.
Teste todas as camadas antes que os invasores o façam
As equipes de segurança registram 54% dos ataques bem-sucedidos e alertam sobre apenas 14%. O restante se move pelo seu ambiente sem ser visto. O whitepaper do Picus mostra como a simulação de violação e ataque testa suas regras de SIEM e EDR para que as ameaças parem de escapar da detecção.
Obtenha o whitepaper
U-Boot é um dos bootloaders de código aberto mais usados no mundo e é encontrado em muitos dispositivos Linux embarcados, incluindo Baseboard Management Controllers (BMCs) de servidores corporativos, equipamentos de rede, sistemas industriais, dispositivos IoT e outros dispositivos.
Como o U-Boot é responsável por carregar o sistema operacional, as vulnerabilidades no bootloader podem permitir que invasores comprometam um dispositivo antes que o sistema operacional e seu software de segurança tenham a chance de iniciar.
Um de seus recursos de segurança, conhecido como inicialização verificada, usa assinaturas criptográficas para garantir que apenas imagens de firmware e sistema operacional assinadas por uma chave confiável sejam carregadas durante a inicialização.
Em um relatório publicado esta semana, a empresa de segurança de firmware Binarly divulgou seis vulnerabilidades no código de verificação de assinatura FIT (Flattened Image Tree) do U-Boot.
"Recognising the critical nature of this component, the Binarly Research team decided to examine the core functionality of the U-Boot project more closely," explains Binarly.
“Esta pesquisa revelou seis vulnerabilidades distintas, variando em impacto desde negação de serviço (DoS) até execução arbitrária de código durante a verificação de uma imagem não confiável.”
Segundo os pesquisadores, duas das falhas podem levar à execução arbitrária de códigos durante a verificação do firmware, enquanto as quatro restantes podem ser exploradas para travar dispositivos vulneráveis.
Como essas falhas afetam o código de validação de imagens de firmware antes do sistema operacional ser iniciado, se um invasor conseguir explorar esse processo, ele poderá executar código malicioso antes do carregamento do sistema operacional.
As seis vulnerabilidades divulgadas são:
BRLY-2026-037: Uma falha que pode fazer com que o U-Boot trave ao processar uma imagem de firmware maliciosa e, sob 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 que invasores executem código arbitrário durante a verificação de assinatura de firmware.
BRLY-2026-039: Uma vulnerabilidade de leitura fora dos limites que pode travar dispositivos, forçando o U-Boot a ler além da imagem do firmware.
BRLY-2026-040: Uma desreferência de ponteiro nulo que permite que imagens de firmware especialmente criadas travem o bootloader.
BRLY-2026-041: Validação inadequada de dados de firmware armazenados externamente que pode causar falha no U-Boot ao processar imagens de firmware maliciosas.
BRLY-2026-042: Uma falha de recursão ilimitada que pode esgotar a memória disponÃvel da pilha e travar o bootloader.
De acordo com a Binarly, a maior parte do código vulnerável existe desde a versão 2013.07 do U-Boot, fazendo com que as falhas afetem potencialmente mais de 50 versões do projeto, bem como fornecedores que utilizaram o código vulnerável em seu próprio firmware.
“Isso significa que elas afetam potencialmente mais de 50 versões estáveis do projeto U-Boot. Contando com muitos forks de fornecedores downstream, essas vulnerabilidades têm um impacto significativo na indústria”, explica Binarly.
Se exploradas com sucesso, as vulnerabilidades de execução arbitrária de código poderão permitir que invasores executem código durante os primeiros estágios do processo de inicialização.
Como isso ocorre antes do carregamento do sistema operacional, os invasores podem desabilitar os recursos de segurança do firmware, modificar o processo de inicialização, instalar malware de firmware persistente ou realizar outras ações maliciosas com altos nÃveis de acesso.
Binarly diz que os maliciosos seriam difÃceis de detectar porque são executados antes do sistema operacional ser iniciado.
Binarly diz que a exploração dessas vulnerabilidades nem sempre requer acesso fÃsico. Em sistemas como BMCs que suportam atualizações remotas de firmware, um invasor que já tenha comprometido a interface de gerenciamento poderá fazer upload de uma imagem de firmware especialmente criada para explorar as falhas.
Binarly relatou as vulnerabilidades aos mantenedores do U-Boot e enviou patches para todos os seis problemas, que desde então foram aceitos na base de código upstream do projeto.
However, because U-Boot is integrated into firmware by individual hardware manufacturers, the fixes must first be incorporated into vendors' firmware updates before they can be distributed to customers.
Dispositivos mais antigos ou sem suporte que não recebem mais atualizações de firmware talvez nunca recebam patches.
Teste todas as camadas antes que os invasores o façam
As equipes de segurança registram 54% dos ataques bem-sucedidos e alertam sobre apenas 14%. O restante se move pelo seu ambiente sem ser visto. O whitepaper do Picus mostra como a simulação de violação e ataque testa suas regras de SIEM e EDR para que as ameaças parem de escapar da detecção.
Obtenha o whitepaper
#samirnews #samir #news #boletimtec #novas #falhas #no #uboot #podem #permitir #ataques #furtivos #de #firmware
⚡ Fique ligado: novidades e promoções em breve por aqui! ⚡
Postar um comentário