FERRAMENTAS LINUX: ldns: o que é, por que você precisa se importar e como corrigir agora

A vulnerabilidade CVE-2026-10846 no ldns permite ataques de envenenamento de cache DNS (off-path poisoning) em aplicações que usam a biblioteca como resolvedor stub via UDP. Aprenda a verificar, corrigir e mitigar o problema no openSUSE com comandos práticos, script de automação e alternativas para ambientes que não podem atualizar imediatamente. Conteúdo atualizado e útil independentemente da data do patch.

O que é o ldns e por que ele é crítico para a segurança do seu sistema

O ldns é uma biblioteca desenvolvida pela NLnet Labs para programação DNS, amplamente utilizada em ferramentas de resolução e diagnóstico como o drill (sucessor do dig em muitos sistemas).

Muitas aplicações no ecossistema openSUSE e SUSE Linux Enterprise dependem dela para consultas DNS — inclusive em servidores, firewalls e sistemas de monitoramento.

A vulnerabilidade CVE-2026-10846 afeta o ldns nas versões 1.2.0 até 1.9.0 (inclusive). Quando a biblioteca é usada como resolvedor stub (ou seja, uma aplicação faz consultas DNS diretamente, sem passar por um resolvedor recursivo local), ela não verifica adequadamente se a resposta recebida pertence de fato à consulta que foi enviada.

Mais especificamente: o ldns não compara o endereço e a porta de destino da consulta com o endereço e a porta de origem da resposta recebida via UDP. Isso permite que um atacante em rota (off-path) — ou seja, alguém na mesma rede ou com capacidade de interceptar/forjar pacotes UDP — injete respostas DNS maliciosas.

O resultado? Envenenamento de cache DNS (DNS cache poisoning), onde sua aplicação pode passar a resolver meubanco.com para o IP de um site falso controlado por criminosos.

Além de aplicações customizadas, a ferramenta drill — que acompanha o ldns — também é vulnerável.

A boa notícia: a correção já foi lançada nas versões 1.9.1 e 1.9.2 do ldns. No openSUSE, o update está disponível para Leap 15.6, Tumbleweed e diversos módulos do SUSE Linux Enterprise.

Como verificar se você está vulnerável

Antes de aplicar qualquer correção, é fundamental saber se seu sistema está exposto.

Verifique a versão instalada do ldns

zypper info ldns | grep Version

Ou, se preferir:

rpm -q ldns

Interpretação: Se a versão for anterior a 1.9.1 (ex.: 1.8.3, como no openSUSE Leap 15.6), você está vulnerável.

Verifique se o pacote ldns está sendo usado por outras aplicações

zypper search --requires ldns

Isso lista todos os pacotes que dependem do ldns. Se você usa ferramentas como drill, unbound (em algumas configurações) ou aplicações próprias que fazem consultas DNS via UDP, a correção é prioritária.

Teste rápido com o drill (se instalado)

drill @8.8.8.8 exemplo.com

Se funcionar, ótimo — mas isso não indica que você está imune à vulnerabilidade. O problema está na validação da resposta, não na capacidade de resolver domínios.

Script de automação para aplicar a correção

Abaixo, um script bash compatível com openSUSE que verifica a versão, baixa a atualização e aplica o patch de forma segura. Execute como root ou com sudo.

#!/bin/bash
# Script: fix_ldns_cve-2026-10846.sh
# Descrição: Verifica e aplica a correção para CVE-2026-10846 no openSUSE
# Compatível com: openSUSE Leap 15.6, Tumbleweed e SUSE Linux Enterprise

set -e

echo "=== CVE-2026-10846 - Correção para ldns ==="
echo "Data: $(date)"

# 1. Verifica versão atual
CURRENT_VERSION=$(rpm -q ldns --qf "%{VERSION}" 2>/dev/null || echo "nao_instalado")

if [ "$CURRENT_VERSION" == "nao_instalado" ]; then
    echo "AVISO: ldns não está instalado. Nada a fazer."
    exit 0
fi

echo "Versão atual do ldns: $CURRENT_VERSION"

# 2. Compara com a versão corrigida (1.9.1 ou superior)
if [[ "$CURRENT_VERSION" > "1.9.0" ]] || [[ "$CURRENT_VERSION" == "1.9.1" ]] || [[ "$CURRENT_VERSION" == "1.9.2" ]]; then
    echo "✓ Seu sistema já está com uma versão corrigida (> 1.9.0)."
    exit 0
fi

echo "⚠  Sistema VULNERÁVEL. Aplicando correção..."

# 3. Atualiza repositórios
echo "Atualizando lista de pacotes..."
zypper refresh

# 4. Aplica o patch específico
echo "Aplicando patch SUSE-2026-2462..."
zypper patch --cve CVE-2026-10846

# 5. Verifica novamente a versão após a atualização
NEW_VERSION=$(rpm -q ldns --qf "%{VERSION}" 2>/dev/null)

echo "Nova versão do ldns: $NEW_VERSION"

if [[ "$NEW_VERSION" > "1.9.0" ]] || [[ "$NEW_VERSION" == "1.9.1" ]] || [[ "$NEW_VERSION" == "1.9.2" ]]; then
    echo "✓ CORREÇÃO APLICADA COM SUCESSO!"
else
    echo "✗ A correção pode não ter sido aplicada. Tente manualmente:"
    echo "  zypper in -t patch SUSE-2026-2462=1"
    exit 1
fi

echo "=== Fim ==="

Como usar:

1. Salve o script como fix_ldns_cve-2026-10846.sh

2. Dê permissão de execução: chmod +x fix_ldns_cve-2026-10846.sh

3. Execute: sudo ./fix_ldns_cve-2026-10846.sh

📗 Recomendação de Leitura

Segurança em servidores Linux: Ataque e Defesa (anúncio) -> https://amzn.to/4ewrCbr

Se você prefere estudar em português e quer aprender a "pensar como um hacker" para se antecipar a invasões, essa é a pedida! O livro ensina a usar as ferramentas prediletas dos invasores (como Nmap e Netcat) a seu favor, blindando seus sistemas.

Eu ganho uma comissão quando você faz uma compra.

Mitigação alternativa caso não possa atualizar agora

Se você não pode reiniciar serviços ou não tem autorização para atualizar neste momento, existem medidas paliativas:

Bloqueie consultas DNS não autorizadas via iptables

Caso sua aplicação só precise consultar um DNS específico (ex.: o DNS da sua empresa ou o 8.8.8.8), você pode restringir o tráfego UDP de saída para apenas esse destino:

# Exemplo: permitir apenas consultas ao Google DNS (8.8.8.8) na porta 53
iptables -A OUTPUT -p udp --dport 53 -d 8.8.8.8 -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -j DROP

Atenção: Isso só funciona se sua aplicação não precisar consultar múltiplos resolvedores. É uma solução temporária e limitada.

Use um resolvedor local (como systemd-resolved ou dnsmasq)

Em vez de a aplicação fazer consultas DNS diretamente (stub resolver), configure-a para usar um resolvedor local que faça a validação correta:

systemd-resolved: já presente na maioria das distribuições modernas.

dnsmasq: leve e fácil de configurar.

Exemplo com dnsmasq (instale com zypper in dnsmasq):

# /etc/dnsmasq.conf
server=8.8.8.8
server=1.1.1.1

Depois, aponte suas aplicações para 127.0.0.1 como DNS.

AppArmor ou SELinux (controle de acesso)

Embora não corrijam a vulnerabilidade, perfis AppArmor rigorosos podem limitar o impacto de um ataque bem-sucedido, restringindo o que a aplicação comprometida pode fazer. No openSUSE:

sudo aa-status
sudo aa-enforce /caminho/para/sua/app

Por que isso importa: DNS poisoning na prática

Um atacante que explore essa falha pode:

Redirecionar tráfego: fazer sua aplicação acessar um servidor falso em vez do legítimo

Interceptar credenciais: se a aplicação fizer login em um serviço, o atacante pode capturar usuário e senha

Derrubar serviços: responder com endereços inválidos, causando negação de serviço

O cenário mais crítico envolve aplicações que resolvem nomes de forma autônoma — como firewalls que consultam listas de bloqueio, sistemas de monitoramento que verificam domínios externos, ou até mesmo scripts de backup que resolvem endereços de servidores remotos.

Conclusão

A vulnerabilidade CVE-2026-10846 no ldns é um lembrete de que bibliotecas fundamentais merecem tanta atenção quanto o sistema operacional. A correção já está disponível para openSUSE e SUSE Linux Enterprise, e o processo é simples: