Mitigação de bug da Glibc para getaddrinfo ()

Question

Executou uma exploração para a glibc hoje, o que envolve a chamada getaddrinfo () Resolução de DNS. Estou executando o Ubuntu 12.04 em duas caixas Bind9 que estão voltadas para a Internet. Não tenho certeza se entendi totalmente a exploração, mas parece ser causada por uma grande resposta de um servidor DNS mal-intencionado. Uma das mitigações é um "firewall que liberta pacotes DNS UDP > 512 bytes" , por isso configurei o netfilter nos servidores DNS para eliminar qualquer UDP > 512 bytes provenientes ou indo para a porta 53: -A INPUT -i lo -j ACCEPT -A INPUT -p udp --sport 53 -m length --length 511:65535 -j DROP -A INPUT -p udp --dport 53 -m length --length 511:65535 -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Existe uma maneira melhor de fazer isso com uma configuração de vinculação ou algo do tipo? Eu testei a regra com scapy e de fato bloqueia um pacote UDP > 512 jogados na porta 53.

ATUALIZADO por respostas: -A INPUT -i lo -j ACCEPT -A INPUT -p udp --sport 53 -m length --length 949:65535 -j DROP -A INPUT -p udp --dport 53 -m length --length 949:65535 -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

e /etc/bind/named.conf.options

options {
   ...
   // 2016-02-17 - tmb - glibc exploit mitigation
   edns-udp-size 900 ;
   max-udp-size 900 ;
};

UPDATE 2 : Como apontado por atdre abaixo, a Cloudflare experimentou a técnica acima e, embora a carga inteira não pôde ser transferida, a corrupção de memória ainda era uma possibilidade. Acho que vou procurar em Unbound .

    

Answer 1

Se você estiver executando o bind localmente, isso fornece um teste:

dig @127.0.0.1 tcf.rs.dns-oarc.net txt

como descrito aqui: link .

Você receberá uma resposta assim:

root@myhost:~# dig @127.0.0.1 tcf.rs.dns-oarc.net txt

; <<>> DiG <<>> @127.0.0.1 tcf.rs.dns-oarc.net txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61575
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 26, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1024
;; QUESTION SECTION:
;tcf.rs.dns-oarc.net.           IN      TXT

;; ANSWER SECTION:
tcf.rs.dns-oarc.net.    60      IN      CNAME   tcf.x981.rs.dns-oarc.net.
tcf.x981.rs.dns-oarc.net. 59    IN      CNAME   tcf.x986.x981.rs.dns-oarc.net.
tcf.x986.x981.rs.dns-oarc.net. 58 IN    CNAME   tcf.x991.x986.x981.rs.dns-oarc.net.
tcf.x991.x986.x981.rs.dns-oarc.net. 57 IN TXT   "Tested at 2016-02-17 15:44:36 UTC"
tcf.x991.x986.x981.rs.dns-oarc.net. 57 IN TXT   "xx.xx.xx.xx DNS reply size limit is at least 991"

e você pode adicionar a opção de vinculação

options {
  ...
  edns-udp-size 1024 ;
  max-udp-size 1024 ;
};

no arquivo named.conf

como descrito aqui: link .

Eu usaria isso em conjunto com outras mitigações também.

    

Answer 2

Enquanto Um firewall que baixa pacotes DNS UDP > 512 bytes. mitiga a exploração (em UDP especificamente, o TCP ainda pode ser um vetor de ataque); também não é um comportamento correto e, em vez disso, quebra outra funcionalidade.

Desde a introdução do EDNS0, não existe tal limite na especificação do DNS e você causará quebras para o tráfego válido simplesmente descartando pacotes.

O que sugere birdwes, com a configuração de um servidor de nomes de resolução para limitar os tamanhos de resposta aos seus clientes é uma maneira melhor como os clientes serão, pelo menos, devidamente notificados (resposta truncada) de acordo com as especificações em vez de apenas silêncio e, eventualmente, um tempo limite, mas a solução adequada é instalar o glibc corrigido (é aí que algo está errado, o tamanho não está errado) .

    

Answer 3

Após alguns testes, a CloudFlare determinou que limitar o tamanho da resposta dos pacotes DNS e desativar o suporte ao EDNS0 não corrigiu o CVE-2015-7547. Você pode testar você mesmo usando o código PoC do autor, disponível como autores vinculados ao longo do post.

Você pode ler sobre suas conclusões e ver os resultados de seus testes aqui - link

CloudFlare diz:

The only good mitigation is to run a DNS resolver on localhost where the attacker can’t introduce resource exhaustion, or at least enforce minimum cache TTL to defuse the waiting game attack.

Fornecendo os seguintes três utilitários úteis como resolvedores de código aberto que você pode instalar e configurar:

1. Não consolidado
2. Recursor do PowerDNS
3. Resolvedor de DNS do Knot

Eles também dizem:

A generally good mitigation is to shield yourself with a local caching DNS resolver, or at least a DNSCrypt tunnel. Arguably, there might be a vulnerability in the resolver as well, but it is contained to the daemon itself—not to everything using the C library (e.g., sudo).