CERT divulga CVEs para 6 vulnerabilidades graves de segurança no dnsmasq

 (lists.thekelleys.org.uk)
1 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • O CERT divulgou em 11 de maio de 2026 um conjunto de CVEs para 6 vulnerabilidades graves de segurança no dnsmasq
  • As vulnerabilidades são todas bugs antigos e afetam quase todas as versões do dnsmasq, exceto algumas versões muito antigas
  • Os CVEs foram divulgados previamente aos fornecedores, e cada fornecedor precisa distribuir em tempo hábil uma versão corrigida do pacote dnsmasq
  • Foi criado o 2.92rel2, com os patches aplicados sobre a versão estável dnsmasq 2.92, e ele pode ser obtido no local de download habitual
  • Em breve será criada a tag dnsmasq-2.93rc1, com meta de lançar a versão 2.93 em cerca de uma semana após os testes

Divulgação das vulnerabilidades e patches do dnsmasq

  • O CERT divulgou em 11 de maio de 2026 um conjunto de CVEs para 6 vulnerabilidades graves de segurança no dnsmasq
  • As vulnerabilidades são todas bugs antigos e se aplicam a quase todas as versões do dnsmasq, exceto algumas muito antigas
  • Os CVEs foram divulgados previamente aos fornecedores, e cada fornecedor precisa distribuir em tempo hábil uma versão corrigida do pacote dnsmasq
  • Os detalhes e os patches podem ser consultados em https://thekelleys.org.uk/dnsmasq/CVE/
  • Foi criado o 2.92rel2, com os patches aplicados sobre a versão estável dnsmasq 2.92, e ele pode ser obtido no local de download habitual
  • No mesmo momento, commits de correção também devem chegar à árvore de desenvolvimento; alguns usam os mesmos patches do backport e outros são reescritas mais abrangentes que tratam a causa raiz

Aumento de relatórios baseados em IA e plano para o 2.93

  • Nos últimos meses, os relatórios de bugs aumentaram muito por causa da pesquisa de segurança baseada em IA, e tem sido necessário muito tempo para remover duplicatas e classificar os bugs
  • Os bugs foram divididos entre itens que exigem divulgação prévia aos fornecedores e itens que é melhor corrigir imediatamente após a divulgação pública; essa distinção é inevitavelmente subjetiva
  • Como vários “good guys” encontraram repetidamente os mesmos bugs, considera-se possível que os “bad guys” também os tenham encontrado, então embargos longos não parecem ter muita efetividade
  • Coordenar embargos e fornecer backports exige muito tempo e esforço de todos os participantes
  • A prioridade para a maioria dos bugs é corrigi-los nas próximas versões e deixar a nova versão do dnsmasq o mais livre de bugs possível
  • O fato de muitos commits de correção de segurança terem sido enviados ao repositório git nas semanas anteriores ao anúncio também vai nessa direção
  • Em breve deve ser criada a tag dnsmasq-2.93rc1, e o objetivo é lançar a versão estável 2.93 o mais rápido possível
  • Testar a release candidate é importante, então quem puder deve testar o quanto antes
  • Se tudo correr bem, a 2.93 pode sair em cerca de uma semana
  • O “tsunami” de relatórios de bugs gerados por IA não dá sinais de parar, então é possível que o mesmo processo se repita em breve
  • Há uma tensão entre refletir no 2.93 o máximo possível do fluxo atual de bugs e lançar a versão no prazo; a prioridade é um lançamento em tempo hábil

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Comentários do Hacker News

  • Parece que estamos chegando a um ponto em que reescrever código feito em C para uma linguagem com segurança de memória está se tornando urgente
    A maior parte das vulnerabilidades descobertas recentemente está diretamente ligada a linguagens sem segurança de memória, e parece muito difícil justificar não escrever servidores DNS/DHCP em Rust ou Go, se possível sem unsafe

    • https://news.ycombinator.com/item?id=47943499 — houve um caso em que tentaram substituir o coreutils por uma nova implementação em Rust e surgiram 44 CVEs. Não existe almoço grátis
    • O problema não é a linguagem, mas a falta de gente qualificada para fazer esse trabalho
      Pesquisadores de segurança com IA pelo menos estão fazendo alguma coisa. Se reescrever tudo em Rust fosse tão fácil assim, deveria ter surgido um substituto robusto em Rust no dia seguinte a esse incidente
      Isso não acontece porque esse tipo de trabalho dificilmente rende estrelas no GitHub
    • Talvez o problema seja a forma como olhamos para a memória dinâmica
      Fico em dúvida se “não sabemos o tamanho máximo, então tudo precisa ser dinâmico” faz mesmo sentido. Não seria o fim do mundo se o programa declarasse um tamanho máximo aceitável para a entrada e, ao ultrapassá-lo, retornasse erro ou usasse um buffer circular
      Se o tamanho pode ser conhecido, dá para projetar em torno disso. A RAM é finita, então é estranho que todas as camadas acima dela sejam projetadas como se fossem infinitas
      Migrar para Rust parece um enorme desperdício de tempo e não resolve o problema fundamental de não modelar os programas de acordo com a realidade de recursos finitos do sistema. E não é só um problema de memória. Casos como o Chrome colocando um modelo de 4GB no dispositivo do usuário são parecidos
    • Não concordo. As proteções estão claramente melhorando graças aos agentes de IA que procuram vulnerabilidades em potencial

  • https://xchglabs.com/blog/dnsmasq-five-cves.html

  • Eu estava curioso para saber se o OpenWRT já tinha lançado uma nova build, e a resposta é que ainda não, mas está em andamento
    https://forum.openwrt.org/t/dnsmasq-set-of-serious-cves/2500...

  • O meu MaraDNS passou por auditorias bem extensas ao entrar na era das auditorias de segurança assistidas por IA
    Desde 2023, não foi encontrado nenhum bug de segurança grave [1]
    Tudo o que os auditores encontraram foram coisas como “o Deadwood leva mais tempo que o normal para liberar recursos ao receber um pacote incomum quando está no modo totalmente recursivo” [2], ou “um utilitário auxiliar incluído no MaraDNS nem compila desde 2022, mas tem um buffer overflow quando $HOME passa de 50 caracteres” [3]
    Pessoalmente, fico muito satisfeito em ver que o MaraDNS é bastante seguro agora que está recebendo auditorias de segurança reais e profundas
    [1] https://samboy.github.io/MaraDNS/webpage/security.html
    [2] https://github.com/samboy/MaraDNS/discussions/136
    [3] https://github.com/samboy/MaraDNS/pull/137

    • Se você empacotou o Lua 5.1 com o Lunacy em vez de torná-lo uma biblioteca carregável, e ainda por cima numa versão de 2012, então provavelmente também pode ser afetado por CVE-2014-5461 e outros
      O Lua também não ficou sem correções de segurança
    • Ainda assim, o MaraDNS é muito menos popular que o dnsmasq
      Eu também tenho algumas bibliotecas que escrevi e nas quais nenhum bug de segurança grave foi encontrado desde 1991. Claro, ninguém usa as minhas bibliotecas
      Não é para diminuir a conquista, mas é importante contextualizar esse tipo de afirmação junto com o tamanho da base de usuários
    • Quando configurei um servidor DNS no passado, fiquei feliz de encontrar o MaraDNS em vez da abordagem “faz-tudo” do dnsmasq e, mais importante, desde então não precisei mais me preocupar com isso
    • Fico curioso, mas não entendo qual é o ponto aqui. Você está dizendo que existe uma alternativa ao dnsmasq, ou que o seu software de alguma forma é “melhor”?
      Essa autopromoção quase não agrega valor à discussão sobre o dnsmasq
      Quanto mais usado um software é, mais ele é revisado, e mais bugs e casos de borda são encontrados
    • Bom trabalho. Mas ainda é surpreendente que, em 2026, continuemos escrevendo ferramentas centrais de rede em uma linguagem frágil como C

  • Ainda bem que esse software não é usado em milhões de dispositivos que quase nunca recebem atualização

    • Quando o fabricante diz “não podemos deixar você usar do jeito que quer”, é bom poder controlar o próprio hardware
    • Pelo menos ajuda o fato de que, na maioria dos casos, isso roda em dispositivos onde o cliente não consegue enviar pacotes sem antes autenticar no Wi‑Fi ou conectar fisicamente na porta Ethernet
    • Y2K26?

  • É bem grave
    “Um invasor remoto que possa fazer consultas DNS ou responder a DNS pode causar uma grande gravação fora dos limites no heap”
    Uma resposta DNS malformada pode “causar um loop infinito e fazer com que o dnsmasq deixe de responder a todas as consultas”
    Solicitações DHCP maliciosas podem causar buffer overflow

  • O tsunami de relatórios de bug por IA não existe em todos os projetos. Como foi dito acima, não houve isso no MaraDNS
    Acho que também não teria acontecido com o djbdns e o tinydns. Se tivesse acontecido, teria sido amplamente divulgado
    Sempre tive dificuldade para entender por que alguns projetos se tornam extremamente populares e outros não
    Também parece que as ferramentas “perigosas demais para divulgar” escaneiam todos os projetos, mas entram em contato seletivamente apenas com os que têm problemas. Assim não precisam admitir que suas ferramentas não encontraram nada

    • Esse tipo de coisa acontece em projetos populares

  • Nunca gostei de usar o dnsmasq. Sempre pareceu que colocava coisa demais em uma ferramenta só
    Sempre preferi configurar separadamente o resolvedor local com cache, o servidor DHCP e a configuração de boot TFTP/PXE

    • Existem alguns recursos do dnsmasq que são difíceis de substituir para certas pessoas
      Por exemplo, encaminhar consultas de *.example.com para um servidor upstream específico, retornar NXDOMAIN para sites de phishing, ou adicionar todos os IPs resolvidos para *.example.org a um ipset para roteamento por política
      O último recurso funciona no FreeBSD mesmo sem existir ipset no BSD. A lista *.example_xyz.com pode ser muito grande, e dizem que o dnsmasq recente lida com isso de forma eficiente
    • Foi por esse tipo de pensamento que há muito tempo passei a usar o MaraDNS para hospedagem DNS
      Nota 10 de 10, sem arrependimentos, recomendável
    • Concordo. Isso também parece ir contra o “jeito Linux” de fazer as coisas
      Por exemplo, o Opnsense usa só a parte de DHCP do dnsmasq e usa o unbound para DNS, e isso parece meio “estranho”
    • Esse é, até certo ponto, o objetivo. O dnsmasq é um aplicativo “toque um roteador pequeno” empacotado em uma caixa só
      DHCP e DNS são ligados entre si, e PXE precisa de entradas de DHCP. Se você quiser uma configuração simples, caso contrário vai precisar costurar pelo menos 3 daemons com sintaxes de configuração diferentes

  • Pergunta de iniciante para quem tem mais experiência nessa área: por que o software desse domínio não é mais escrito sobre runtimes com coleta de lixo e concorrência, como Erlang?

    • A primeira versão do dnsmasq saiu em 2001. Na época, a lista de linguagens realisticamente utilizáveis para servidores de rede de alto desempenho não era tão grande, e Erlang não estava nela
      A perda de desempenho era grande demais, havia um runtime opaco cujo nível de estabilidade era difícil de avaliar na época, havia poucos contribuidores, e a pegada de dependências era grande para algo que não vinha instalado na maioria dos sistemas
      Mesmo por volta de 2015, quando usei Erlang em sistemas de produção, ele ainda tinha arestas quando você saía um pouco do caso de uso para o qual foi originalmente pensado. Não é uma crítica exclusiva ao Erlang; muitas linguagens e runtimes eram parecidos
      Muitos dos sistemas que vão continuar levando pancada nas próximas semanas ou meses têm uma origem parecida. No caso do kernel Linux, a única alternativa em potencial disponível na época era mais ou menos C++. O OpenSSL, um frequentador habitual de problemas de segurança, começou em 1998
      Concordo muito fortemente com a frase “não escreva novos projetos com acesso à rede em C”, mas é difícil dizer qual outra opção teria sido realista se voltássemos para 1998
      Existiam linguagens mais seguras, mas suas comunidades eram muito menores que a de C, e também era difícil garantir sua estabilidade. Java já existia, mas não sei exatamente quando ele se tornou um candidato sério para servidores de rede; eu colocaria isso ali pelo fim dos anos 2000. O Java que eu vi em 1999 ainda não era isso
      Por exemplo, em 2011 eu operava um servidor de rede em Haskell para um uso relativamente pouco importante, e ele caía em condições que, numa rede de produção, nem seriam tão extremas. Quando reutilizei a mesma base de código em 2013 sem mudar o loop principal de execução, melhorou uns 90%, então considero que o problema era mais do lado do Haskell do que do meu código
      Ainda assim, não era algo que eu colocaria em produção de verdade, mas ao menos mostrou que a falha não era do meu código. Isso também indica que, mesmo que Haskell existisse nos anos 2000, seria difícil considerá-lo uma opção realista para servidores de rede naquela época
      Hoje temos muito mais opções do que antes
    • Em C, normalmente dá para mapear struct diretamente para pacotes de rede, o que é bastante fácil
      Em outras linguagens, muitas vezes isso não é tão simples
      Claro, também existe a questão de ser mais lento e mais pesado