Nas bibliotecas padrão C uClibc e uClibc-ng, usadas em muitos dispositivos embarcados e portáteis, foi identificada uma vulnerabilidade (CVE não atribuído), que permite a inserção de dados falsos no cache DNS, podendo ser utilizada para substituir no cache o endereço IP de um domínio aleatório e redirecionar acessos ao domínio para o servidor do invasor.
O problema afeta várias firmwares Linux para roteadores, pontos de acesso e dispositivos de Internet das Coisas, bem como distribuições Linux para sistemas embarcados, como OpenWRT e Embedded Gentoo. Observa-se que a vulnerabilidade se manifesta em dispositivos de vários fabricantes (por exemplo, uClibc é usado nas firmwares Linksys, Netgear e Axis), mas como a vulnerabilidade em uClibc e uClibc-ng permanece não corrigida, informações detalhadas sobre dispositivos e fabricantes específicos, cujos produtos estão com a vulnerabilidade, ainda não foram divulgadas.
A vulnerabilidade é causada pelo uso de identificadores de transação previsíveis no código de envio de requisições DNS. O número de identificação da requisição DNS era escolhido por meio de um simples incremento de um contador sem aplicação de randomização adicional dos números de porta, o que permitia a contaminação do cache DNS através do envio antecipado de pacotes UDP com respostas falsas (a resposta será aceita se chegar antes da resposta real e inclui um ID correto). servidor Diferentemente do método proposto em 2008 por Kaminsky, o identificador de transação não precisa ser adivinhado, pois é originalmente previsível (inicialmente é definido como 1, que é incrementado a cada requisição, em vez de ser escolhido aleatoriamente).
Na especificação para proteção contra adivinhação de identificadores, recomenda-se também a aplicação de uma distribuição aleatória dos números de portas de rede de origem a partir das quais são enviados os pedidos DNS, o que compensa o tamanho insuficientemente grande do identificador. Ao habilitar a randomização das portas para a formação de uma resposta falsa, além de adivinhar o identificador de 16 bits, é necessário também adivinhar o número da porta de rede. Em uClibc e uClibc-ng, essa randomização não foi explicitamente incluída (ao chamar bind, não se especificava uma porta UDP de origem aleatória) e sua aplicação dependia das configurações do sistema operacional.
Ao desativar a randomização de identificadores, a determinação do identificador de requisição incrementável é considerada uma tarefa trivial. Mesmo com a randomização em uso, o atacante precisa apenas adivinhar a porta de rede de um intervalo entre 32768 e 60999, o que pode ser feito por meio do envio massivo simultâneo de respostas falsas para diferentes portas de rede.
A presença da vulnerabilidade foi confirmada em todas as versões atuais do uClibc e do uClibc-ng, incluindo as versões mais recentes uClibc 0.9.33.2 e uClibc-ng 1.0.40. Em setembro de 2021, informações sobre a vulnerabilidade foram enviadas para o CERT/CC para a coordenação da preparação de correções. Em janeiro de 2022, dados sobre o problema foram repassados a mais de 200 fabricantes que colaboram com o CERT/CC. Em março, houve uma tentativa de entrar em contato separadamente com o projeto uClibc-ng, mas receberam a resposta de que não eram capazes de corrigir a vulnerabilidade de forma independente e recomendaram divulgar publicamente as informações sobre o problema, esperando obter ajuda da comunidade no desenvolvimento de uma correção. Dentre os fabricantes, a NETGEAR anunciou o lançamento de uma atualização que corrige a vulnerabilidade.
Fonte: opennet.ru
