Foram detectadas seis vulnerabilidades no Buildroot que permitem execução remota de código

vulnerabilidade

Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas

Faz pouco Cisco Talos (a divisão de pesquisa e desenvolvimento de segurança cibernética da Cisco Systems) tornou conhecido, por meio de uma postagem no blog, informações sobre a descoberta de uma série de vulnerabilidades no sistema de compilação Buildroot.

Cisco Talos Menciono a descoberta de seis vulnerabilidades em Buildroot que permite, durante a interceptação do tráfego de trânsito (MITM), faça alterações nas imagens do sistema geradas ou organize a execução do código no sistema de construção.

As primeiras cinco vulnerabilidades catalogado em TALOS-2023-1844 See More (CVE-2023-45841, CVE-2023-45842, CVE-2023-45838, CVE-2023-45839, CVE-2023-45840) afetar o código para verificar a integridade dos pacotes usando hashes.

Os problemas Eles se resumem à capacidade de usar HTTP para baixar arquivos e à falta de hashes de verificação de arquivos para alguns pacotes, permitindo que o conteúdo desses pacotes seja substituído, tendo a oportunidade de interferir no tráfego do servidor de construção (por exemplo, quando um usuário se conecta através de uma rede sem fio controlada por um invasor).

Como os pacotes podem incluir arquivos de patch ou Makefiles, ao fornecer um pacote fonte comprometido, um invasor pode executar comandos arbitrários no compilador. Como consequência direta, um invasor também pode alterar quaisquer arquivos gerados para alvos e hosts do Buildroot.

Em particular, os pacotes aufs e aufs-util foram carregados por HTTP e não foram comparados com hashes. Também faltam hashes para os pacotes riscv64-elf-toolchain, versal-firmware e mxsldr, que eram carregados por HTTPS por padrão, mas voltavam para downloads não criptografados em caso de problemas. Se não houvesse arquivos ".hash", a ferramenta Buildroot considerou a verificação bem-sucedida e processou os pacotes baixados, incluindo a aplicação de quaisquer patches incluídos nos pacotes e a execução de scripts de construção.

Ao ter a capacidade de falsificar pacotes baixados, o invasor pode adicionar seus próprios patches ou Makefiles a eles, permitindo que alterações sejam feitas na imagem resultante ou criando scripts de sistema e executando seu código.

Na parte de a sexta vulnerabilidade que foi classificado em TALOS-2023-1845 See More (CVE-2023-43608) é causado por um erro na implementação da funcionalidade BR_NO_CHECK_HASH_FOR, que permite desabilitar as verificações integridade de hash para pacotes selecionados.

É mencionado que olhar:

Cada linha hash no arquivo .hash é chamada check_one_hash. Se o hash não corresponder, check_one_hash sairá com um código de erro. Caso contrário, nb_checks será incrementado para indicar uma verificação bem-sucedida. Se não houver nenhuma entrada no arquivo .hash para verificar o arquivo de entrada especificado, a verificação na condição IF retornará um erro, a menos que BR_NO_CHECK_HASH_FOR[9] contenha este arquivo específico, o que significa que o arquivo é excluído das verificações de hash.

No total, Existem 3 maneiras de verificar o hash retorna o valor 0:

  1. .hash não existe arquivo para o pacote
  2. $file hash corresponde à definição do arquivo .hash
  3. $file não está presente no arquivo .hash e BR_NO_CHECK_HASH_FOR contém o nome base do pacote (ignorando explicitamente as verificações)

Para o conceito de demonstração de vulnerabilidade, os desenvolvedores focados na opção 3, pois isso parece ser comumente usado para ignorar verificações de integridade de recursos que não podem ser facilmente criptografados (por exemplo, recursos de desenvolvimento que mudam com frequência). Também é usado ao criar versões específicas de um pacote, para as quais os hashes podem não estar disponíveis nas fontes do Buildroot.

Alguns pacotes, como o kernel Linux, U-Boot e versal-firmware, permitiam carregar as versões mais recentes para as quais os hashes de verificação ainda não haviam sido gerados. Para essas versões foi utilizada a opção BR_NO_CHECK_HASH_FOR, que desabilita a verificação de hash.

Os dados foram baixados por HTTPS, mas por padrão, caso o download falhasse, era utilizada uma alternativa para acessar o site sem criptografia usando o protocolo http://. Durante um ataque MITM, um invasor pode bloquear a conexão com o servidor HTTPS e o download ser revertido.

Finalmente, deve ser mencionado que vulnerabilidades são resolvidas nas versões mais recentes do Buildroot e se você estiver interessado em saber mais sobre isso, você pode consultar os detalhes no link a seguir.