Вопросы Теги

Устранение ошибок Glibc для getaddrinfo ()

Сегодня наткнулся на эксплойт для glibc, который включает вызов getaddrinfo () для разрешения DNS. Я запускаю Ubuntu 12.04 на двух устройствах Bind9, выходящих в Интернет. Я не уверен, что полностью понимаю эксплойт, но, похоже, он вызван большим ответом от вредоносного DNS-сервера. Одним из способов решения этой проблемы является «брандмауэр, отбрасывающий UDP-пакеты DNS> 512 байт» , поэтому я настроил netfilter на DNS-серверах, чтобы отбрасывать любые UDP> 512 байт, приходящие или идущие на порт 53: -A ВВОД -i lo -j ПРИНЯТЬ -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

Есть ли лучший способ сделать это с помощью параметра Bind или чего-то еще? Я протестировал правило с помощью scapy, и оно действительно блокирует UDP-пакет> 512, отправленный на порт 53.

ОБНОВЛЕНО для ответов: -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 СВЯЗАН, УСТАНОВЛЕН -j ПРИНЯТЬ

и /etc/bind/ named.conf.options 

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

ОБНОВЛЕНИЕ 2 : Как указано ниже в atdre , Cloudflare попробовал описанный выше метод, и хотя вся полезная нагрузка не могла быть передана, повреждение памяти все еще оставалось возможным. Думаю, я изучу Несвязанный .

4
задан 13 April 2017 в 15:14
3 ответа

Если вы запускаете привязку локально, это дает вам тест: 

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

, как описано здесь: https://www.dns-oarc.net/oarc/services/replysizetest .

Вы получите такой ответ: 

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"

, и вы можете добавить параметр привязки 

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

в файл с именем.conf

, как описано здесь: https: // labs. спелые.net / Members / anandb / content-testing-your-resolver-dns-reply-size-issues .

Я бы также использовал это вместе с другими средствами защиты.

3
ответ дан 3 December 2019 в 02:32

Хотя Межсетевой экран, отбрасывающий UDP-пакеты DNS размером> 512 байт. смягчает эксплойт (в частности, через UDP, TCP все еще может быть вектором атаки) это также неправильное поведение и вместо этого нарушает другие функции.

С момента введения EDNS0 в спецификации DNS нет такого ограничения, и вы вызовете поломки для допустимый трафик, просто отбрасывая пакеты.

То, что предлагает Birdwes, с настройкой сервера имен резолвера для ограничения размеров ответа обратно своим клиентам - лучший способ, поскольку клиенты будут по крайней мере должным образом уведомлены (усеченный ответ) в соответствии со спецификациями, а не просто тишина и, в конечном итоге, тайм-аут, но правильным решением является установка исправленной glibc (вот где что-то не так, размер не тот) .

6
ответ дан 3 December 2019 в 02:32

После небольшого тестирования CloudFlare определила, что ограничение размера ответа DNS-пакетов и отключение поддержки EDNS0 не исправляет CVE-2015-7547. Вы можете проверить себя, используя PoC-код автора, доступный в виде связанных ссылок на протяжении всего сообщения.

Вы можете прочитать об их выводах, а также увидеть результаты их тестов здесь - https: //blog.cloudflare .com / a-story-of-a-dns-exploit-cve-2015-7547 /

CloudFlare говорит:

Единственное хорошее средство защиты - запуск DNS-преобразователя на локальном хосте, где злоумышленник не может ввести ресурс исчерпание, или, по крайней мере, обеспечить минимальный TTL кеша для защиты от ожидающей атаки игры.

Предоставление следующих трех полезных утилит в качестве преобразователей с открытым исходным кодом, которые вы можете установить и настроить:

  1. Unbound
  2. PowerDNS Recursor
  3. Knot DNS Resolver

Они также говорят:

Как правило, хорошим средством защиты является защита себя с помощью локального кэширующего DNS-преобразователя или, по крайней мере, туннеля DNSCrypt . Возможно, уязвимость может быть и в резолвере, но она содержится в самом демоне, а не во всем, что использует библиотеку C (например, sudo).

2
ответ дан 3 December 2019 в 02:32

Теги

Похожие вопросы