Введение: Почему безопасность dnsmasq касается каждого

Представь: ты подключаешься к Wi-Fi в любимой кофейне или деплоишь очередной микросервис в Kubernetes. Между тобой и интернетом стоит крошечный, почти незаметный посредник — dnsmasq. Он работает в твоем домашнем роутере (OpenWrt, DD-WRT), в Android-смартфоне и даже в огромных облачных кластерах. Этот «невидимый швейцарский нож» сетевой инфраструктуры годами считался эталоном легкости и надежности.

Но что, если этот фундамент даст трещину? Недавний отчет CERT (Computer Emergency Response Team) о выявлении шести критических уязвимостей в dnsmasq стал холодным душем для DevOps-инженеров и системных администраторов. Ошибки в коде позволяют не просто «уронить» сеть, но и выполнить произвольный код (RCE) или подменить адреса сайтов через «отравление кэша». Учитывая, что dnsmasq стоит везде, под угрозой оказались сотни миллионов устройств.

В этой статье мы разберем, как именно хакеры могут использовать эти бреши и почему «защитный» протокол DNSSEC внезапно стал слабым звеном.

1. Архитектурные особенности dnsmasq и корень проблем

Чтобы понять, как возникли эти дыры, нужно заглянуть «под капот». В отличие от тяжеловесного BIND, dnsmasq написан на чистом C с маниакальной страстью к экономии ресурсов. Он не хранит всю базу интернета, а просто пересылает запросы и запоминает ответы.

Проблема в том, что в погоне за скоростью разработчики порой жертвовали безопасностью работы с памятью. Протоколы DNS и DHCP — это хаос из бинарных данных переменной длины. Представь, что ты пытаешься впихнуть невпихуемое в жестко заданные границы массива. Исторически dnsmasq оптимизировался так, чтобы летать на «железе» с 16 МБ оперативной памяти, что и создало почву для классических ошибок: переполнения буфера и некорректной проверки границ.

Иронично, но большинство новых CVE связаны с реализацией DNSSEC. Протокол, созданный для защиты интернета, стал вектором атаки из-за сложности его реализации в коде, ориентированном на минимализм.

2. Детальный разбор уязвимостей: От RCE до Cache Poisoning

Эксперты CERT разделили проблемы на две группы: «кровавое» повреждение памяти и тонкие манипуляции с логикой запросов.

Группа А: Когда память «течет» (Memory Corruption)

Эти уязвимости — самый страшный сон админа, так как они открывают дорогу к удаленному выполнению кода (RCE).

  • CVE-2020-25681: Переполнение кучи при обработке DNSSEC-записей. Хакер присылает ответ с аномально длинной записью RR (Resource Record), и dnsmasq «захлебывается», перезаписывая соседние области памяти своими данными.
  • CVE-2020-25682: Ошибка при проверке подписей DNSSEC. Из-за неосторожного использования функции memcpy(), данные из пакета вылетают за пределы выделенного буфера.
  • CVE-2020-25683: Уязвимость в функции get_rdata. Отсутствие проверки длины позволяет атакующему захватить контроль над процессом, просто отправив «правильно» испорченный пакет.
  • CVE-2020-25687: Еще одно переполнение при валидации специфических типов RR-записей.

Сценарий атаки прост: злоумышленнику достаточно дождаться, пока устройство сделает DNS-запрос, и подсунуть фальшивый ответ быстрее настоящего сервера. В условиях публичного Wi-Fi или скомпрометированного провайдера это делается за доли секунды.

Группа Б: Уязвимости DNSpooq (Cache Poisoning)

Вторая группа уязвимостей касается логики...

Заключение: Как не стать жертвой «невидимого» врага

История с dnsmasq — это напоминание о том, что даже самый проверенный софт нуждается в ревизии. Если в твоей инфраструктуре есть роутеры, IoT-устройства или k8s-кластеры, не жди «удачного момента».

Что делать прямо сейчас? Проверь версию dnsmasq. Исправления вошли в релиз 2.83. Если ты используешь OpenWrt или Android — проверь наличие патчей от производителя. Безопасность — это не состояние, а процесс. Обновись сегодня, чтобы завтра не разгребать последствия взлома всей сети из-за одной маленькой утилиты.