The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимости в dnsmasq, допускающие отравление DNS-кэша и выполнение кода с правами root

12.05.2026 17:53 (MSK)

В пакете Dnsmasq, объединяющем кэширующий DNS-резолвер, сервер DHCP, сервис для анонсов маршрутов IPv6 и систему загрузки по сети, выявлено 6 уязвимостей, позволяющих выполнить код с правами root, перенаправить домен на другой IP, определить содержимое памяти процесса и вызвать аварийное завершение сервиса. Проблемы устранены в выпуске dnsmasq 2.92rel2. Исправления также доступны в форме патчей.

Выявленные проблемы:

  • CVE-2026-4892 - переполнение буфера в реализации DHCPv6, позволяющее атакующему, имеющему доступ к локальной сети, выполнить код с правами root через отправку специально оформленного пакета DHCPv6. Переполнение вызвано тем, что при записи DHCPv6 CLID в буфер не учитывалось то, что в пакете данные сохраняются в шестнадцатеричном представлении, в котором используется три байта "%xx" на каждый фактический байт CLID (например, сохранение 1000-байтового CLID приведёт к записи 3000 байт).
  • CVE-2026-2291 - переполнение буфера в функции extract_name(), позволяющее атакующему подставить фиктивные записи в кэш DNS и добиться перенаправления домена на другой IP-адрес. Переполнение возникло из-за выделения буфера без учёта экранирования некоторых символов во внутреннем представлении доменного имени в dnsmasq.
  • CVE-2026-4893 - утечка информации, позволяющая обойти проверку через отправку специально оформленного DNS-пакета с информацией о подсети клиента (RFC 7871). Уязвимость может использоваться для изменения маршрута DNS-ответа и перенаправления пользователей на домен атакующего. Уязвимость вызвана тем, что в функцию check_source() передавалась длина записи OPT вместо длины пакета, из-за чего функция всегда возвращала успешный результат проверки.
  • CVE-2026-4891 - чтение из области вне границы буфера при валидации DNSSEC, приводящее к утечке в ответе данных из памяти процесса при обработке специально оформленного DNS-запроса.
  • CVE-2026-4890 - зацикливание при валидации DNSSEC, позволяющее вызвать отказ в обслуживании через отправку специально оформленного DNS-пакета.
  • CVE-2026-5172 - чтение из области вне буфера в функции extract_addresses(), приводящее к аварийному завершению при обработке специально оформленных DNS-ответов.

Статус устранения уязвимостей в дистрибутивах можно оценить на данных страницах (если страница недоступна, значит разработчики дистрибутива ещё не приступили к рассмотрению проблемы): Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch, Fedora, OpenWRT, FreeBSD. Проект Dnsmasq задействован в платформе Android и специализированных дистрибутивах, таких как OpenWrt и DD-WRT, а также в прошивках беспроводных маршрутизаторов многих производителей. В обычных дистрибутивах Dnsmasq может устанавливаться при использовании libvirt для обеспечения работы DNS-сервиса в виртуальных машинах или активироваться в конфигураторе NetworkManager.

  1. Главная ссылка к новости (https://www.kb.cert.org/vuls/i...)
  2. OpenNews: Проект Dnsmasq стал обладателем первой премии BlueHats
  3. OpenNews: Уязвимости в Dnsmasq, позволяющие подменить содержимое в кэше DNS
  4. OpenNews: Уязвимости в Dnsmasq, позволяющие удалённо выполнить код атакующего
  5. OpenNews: Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS
  6. OpenNews: Уязвимости KeyTrap и NSEC3, затрагивающие большинство реализаций DNSSEC
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65431-dnsmasq
Ключевые слова: dnsmasq
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (91) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 18:03, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    У всех нормальных unbound.
     
     
  • 2.3, Аноним83 (?), 18:07, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А DHCPv6 чем раздавать?)
     
     
  • 3.10, Аноним (10), 18:28, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Kea.

    Плюс для дома это редко нужно. А вот dns сервер с поддержкой doh, резолвера и кеша нужен всегда. Вечно дергать glibc - глупая затея.

     
     
  • 4.22, Аноним83 (?), 19:37, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Kea тяжёловата и сложновата.

    Мне DoH/DoT даром не нужны, я порезал все известные IP этих сервисов дома, чтобы туда не лазали всякие андройды в обход домашнего unbound с его чёрными списками.

    Не очень понял как вы из приложения мимо системного резолвера попадёте в кеш unbound?

     
     
  • 5.49, Аноним (49), 21:17, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Не очень понял как вы из приложения мимо системного резолвера попадёте в кеш unbound?

    Ну если приложение берет сервера не из /etc/resolv.conf, то никак.

    Разве что руткит прикрутить и хуки повесить. Но это уже такой момент.

     
     
  • 6.55, Аноним83 (?), 22:15, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вот взяло приложение из resolv.conf
    nameserver 127.0.0.1

    дальше то оно libc и будет дёргать.
    Если речь шла про то что кеш не покидает хоста или локалки (смотря где unbound) стоит - то это да, в остальных случаях я только про кеш внутри приложений встречал, но это каждый раз отдельные реализации.

     
     
  • 7.60, Аноним (60), 22:34, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > кеш не покидает хоста или локалки (смотря где unbound) стоит

    Верно, сорри. Неправильно выразился.

    > в остальных случаях я только про кеш внутри приложений встречал,

    Да, у тех же браузеров есть, секунд 60, наверное.

     
  • 3.39, wd (?), 20:20, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    а зачем его раздавать? там же slaac есть, очень даже работает
     
     
  • 4.40, Аноним83 (?), 20:29, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не точно выразился: чем IPv6 адреса раздавать?

    Стоит проблема контроля того какие хосты в сети какие IP адреса юзают.
    Для IPv4 я просто статику по дхцп выдаю, а с IPv6 они сами пачками адреса гребут по RA.

     
     
  • 5.66, Аноним (66), 01:41, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    MAC рандомный выключи на девайсах, где жто не нужно, и будет у тебя статичный айпишник в IPv6. Приватность, если что, ещё включить надо на компах, а телефонам пофигу, они и так у тебя в dhcp могут привторится каким угодно MAC и получить любой айпишник, или вообще не пользоваться твоим DHCP и самоприсвоить статику.
     
     
  • 6.70, Аноним83 (?), 01:55, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Тут дело в управлении внутри своей локалки.
    Допустим я бы детям коей чего резал на фаере, но IPv6 не даёт возможности это делать гарантированно.
    Потом никакой отчётности и статистики, даже сходу не понять кто выжрал весь канал в случае чего: если ип4 можно слазать-посмотреть в базу лиз днсмаска, то ипв6 - это квест через мак адрес.
     
  • 3.42, Аноним (42), 20:42, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Обнови dnsmasq
     
     
  • 4.50, Аноним (49), 21:18, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    И что, там doh есть?

    + Другие фишки типа prefetch и т.д

     
  • 2.4, Аноним (4), 18:08, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    он разжирел с годами. Я может не нормальный, у меня dnsmasq
     
     
  • 3.24, Аноним83 (?), 19:40, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, это точно.
    Заглянул вчера в доку, после примерно 5 лет не заглядывания - а там столько всякого наросло.
    С другой стороны там до сих пор не сделали фильтр для IPv6 записей, ктогда как для IPv4 есть - типа не по феншую, так и приходится через ж. фильтровать некоторые домены от IPv6.

    dnsmasq не имеет рекурсера, это существенный недостаток.

    А ещё там внутри начинка мне не нравится - как раз в декабре там лазал, смотрел на DHCP часть, чувствуется что писали люди из 90х.

     
     
  • 4.53, Заноним (?), 21:50, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > dnsmasq не имеет рекурсера, это существенный недостаток.

    имеет.

     
     
  • 5.56, Аноним83 (?), 22:20, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    https://wiki.archlinux.org/title/Dnsmasq
    Since dnsmasq is a stub resolver not a recursive resolver you must set up forwarding to an external DNS server.

    https://thekelleys.org.uk/dnsmasq/doc.html
    The DNS subsystem provides a local DNS server for the network, with forwarding of all query types to upstream recursive DNS servers and caching of common record types

    Те своего рекурсера там нет, он всегда спрашивает у кого то и тот кто то сам бегает по всем днс начиная с корня пока не найдёт нужное и не отдаст ему.

    Я когда то писал сам рекурсер для днс - очень запарная тема.
    А написать такой как днсмаск весьма просто.

     
  • 2.21, Аноним (21), 19:25, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Роутеров?
     
     
  • 3.28, Аноним83 (?), 19:46, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У роутеров нынче столько лишней памяти что unbound там прекрасно живёт.
    Он в общем то и на 64мб озу уже жить может, в OpenWRT или самом unbound есть пресет под минимальное потребление памяти как раз.
    Я его как раз юзал в мобильных роутерах с OpenWRT, там правда есть нюансы настройки, я их у себя в вики описывал.
     
     
  • 4.63, Аноним (21), 00:09, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В 64 Мб, я думаю, уже и графическое окружение можно какое-то впихнуть. Вопрос только -- зачем? Зачем значительную часть оперативной памяти отдавать под одну единственную программу-демон, которая выполняет одну из десятка функций?
     
     
  • 5.65, Аноним83 (?), 00:31, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У меня там списки блокировки всяких негодных доменов, мне такой сервис нужен.
    А под что ещё память роутера использовать?
     
     
  • 6.75, Аноним (21), 08:43, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня там списки блокировки всяких негодных доменов, мне такой сервис нужен.

    Говоришь так, будто бы dnsmasq не умеет такова.
    А вот наоборот, unbound, например, не умеет в DHCP.

     
     
  • 7.83, Аноним83 (?), 11:34, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    dnsmasq хороший и мне его долго хватало.
    Но unbound лучше работает с DNS, я его брал в основном из за рекурсера, чтобы перестать бегать и собирать везде списки рабочих DNS с кешем и рекурсией - побиратся надоело :)
     
  • 2.92, Аноним (92), 13:56, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >У всех нормальных unbound.

    У кого не unbound - те ненормальные? Латентный шовинизм, прорывающийся вербально.

     

  • 1.2, Аноним83 (?), 18:07, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    На самом деле там практически все косяки были с DNSSEC, ещё пара с DHCPv6 и один с DNS.

    На практике от этого толку около нуля, учитывая что DHCPv6 только в локалке и обычно его не юзают, а DNSSEC вендоры вроде не включают, ибо им не нужны багрепорты на пустом месте.

    Меня вообще никак не задело, ибо у меня оно пока чисто как DHCPv4 сервер, да и то надеюсь не долго осталось.

    Для особо озабоченных - можно dnsmasq в chroot убрать и свести ущерб от всех атак примерно к нулю.

    Я уже почти все сервисы поубирал в chroot, и буду теперь как мяв с её томоей - смотреть за цирком со стороны :)

     
     
  • 2.14, Аноним (14), 19:04, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > свести ущерб от всех атак примерно к нулю

    Чудны дела твои... Что, от отравления кэша DNS chroot помогает? Вот это нанотехнологии!

     
     
  • 3.25, Аноним83 (?), 19:41, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А отравление кеша DNS вообще малозначительная проблема, с около нулевым ущербом.
     
  • 3.67, Аноним (66), 01:45, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    От отравления кэша помогает только DNSSEC либо туннель вокруг того, кто его тебе отравляет (твой провайдер, больше собственно то и некому).
     
     
  • 4.69, Аноним83 (?), 01:52, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    От отравления кеша помогает DNS@TCP - изначально заложенный в протоколе.
    DNSSEC помогает обчебурнетится на ровном месте.
     
  • 2.16, Аноним (10), 19:08, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Меня вообще никак не задело, ибо у меня оно пока чисто как DHCPv4 сервер, да и то надеюсь не долго осталось.

    Ну, значит можно не фиксить rcешки

    > chroot

    После недавних copy fuck и dirty fag? Шутник.

    > смотреть за цирком со стороны :)

    Шею свернешь) Твой чрут в пять секунд разберут и пойдут плясать вокруг тебя.

    > Я уже почти все сервисы поубирал в chroot

    Systemd с namespace и seccompo попробуй.

     
     
  • 3.26, Аноним83 (?), 19:43, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > После недавних copy fuck и dirty fag? Шутник.

    Ээээ так там в chroot только RO область, и бинарник того же dnsmasq+либы ему необходимые.
    И конфиг.
    Что ты с этим сделаешь то?
    Запишешь в /tmp - а от туда не запускается, ибо noexec+nosuid.

     
     
  • 4.54, Аноним (60), 22:14, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Ээээ так там в chroot только RO область, и бинарник того же dnsmasq+либы ему необходимые.

    Тут спасает то, что это кастомный костыль и вероятность, что эксплойт учитывает этот сценарий минимальна.

    А так, если есть RCE в dnsmasq и LPE в ядре, исход может быть печальным.

     
     
  • 5.57, Аноним83 (?), 22:26, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    ...или закладка в железе типа ME/PSP...

    Вопрос то всегда в цене.
    Если готовы заплатить достаточно - то и физически могут вломится, устроить термальный анализ и тп, вы почему то всё сводите к дешман скрипткидди взломам.

    RCE то допустим там есть, но тоже они разные бывают.
    В случае с chroot где все под RO нужно чтобы rce влил кусок кода прямо в память процесса и передал ему управление. Подобное водится в штучных экземплярах в принципе.
    Для LPE тоже часто разные условия бывают, может так легко оказатся что, например, нужное устройство просто не проброшено в chroot.

     
  • 2.20, Аноним (20), 19:23, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Для особо озабоченных - можно dnsmasq в chroot убрать и свести ущерб от всех атак примерно к нулю.

    Во-первых, из chroot-а можно отностельно тривиально выйти. Во-вторых, chroot вам абсолютно никак в данном вопросе не поможет. В-третьих, systemd изобретён.

     
     
  • 3.27, Аноним83 (?), 19:44, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Как вы от туда собрались выходить, когда там ничего нет и писать почти некуда?
     
     
  • 4.51, Аноним (20), 21:27, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Для того, чтобы выйти из chroot, нужно всего-лишь иметь возможность выполнять системные вызова.
     
     
  • 5.58, Аноним83 (?), 22:29, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    И всего лишь быть запущенным под рутом, это вам не вин9х.
     
     
  • 6.62, Аноним (20), 22:38, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    А слабо было сразу написать все параметры?
     
  • 3.36, Аноним (36), 20:11, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >из chroot-а можно отностельно тривиально выйти

    Правда что-ли? Поделись сакральным знанием. Расскажи как "тривиально" выходят из пустого чрута, в котором кроме необходимых либ и единственного исполняемого файла больше ни чего нет и отсутствуют права записи ни в один каталог.

     
     
  • 4.68, Аноним (66), 01:51, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Зачем тогда chroot, если можно демона просто в отдельный UID посадить и дать ему CAP_NET_BIND_SERVICE (или CAP_NET_RAW если ещё и DHCP нужен)? Он всё равно нихрена не сделает. И если в программе был баг, то в теории оно само себе может замапить read-write-execute память и развернуть себе шелл самостоятельно.
     
     
  • 5.81, Аноним83 (?), 11:28, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот в том и дело, что разворачивать этот шелл придётся с нуля - потому что в chroot окружении его нет, и делать это придётся в памяти процесса - тк места где можно поисать под noexec+nosuid смонтированы.
    А потом когда шелл будет развернут (в памяти процесса) окажется что это доступ в никуда - в лучшем случае данные отнесённые к приложению можно прочитать.
     

  • 1.5, Аноним (5), 18:12, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Проблемы устранены в выпуске dnsmasq 2.92rel2.

    Сейчас конечно уязвимости становятся ещё более опасными:
    https://www.tomshardware.com/tech-industry/cyber-security/standard-90-day-vuln

     
     
  • 2.48, Аноним (5), 21:14, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    AI устроил переполох.
     

  • 1.6, Дырик (?), 18:15, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    There has been something of a revolution in AI-based security research,
    and I've spent a lot of time over the last couple of months dealing with
    bug reports, weeding duplicates (so many duplicates!) and triaging bugs
    into those which need vendor pre-disclosure and those which it's better
    to make public and fix immediately.

    The tsunami of AI-generated bug reports shows no signs of stopping, so
    it is likely that this process will have to be repeated again soon.

     
     
  • 2.91, Аноним (92), 13:53, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не более чем, ранее, вычислительные методы исчисления интегралов, например.
     

  • 1.7, ruroruro (ok), 18:21, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Уважаемые админы OpenNET, вы можете в новостях про уязвимости сразу писать - это Local Privilege Escalation (LPE) или Remote Code Execution (RCE)?

    Потому что для подовляющего большинства людей LPE и RCE имеют абсолютно разные уровни важности. А фразы вроде "система загрузки по сети" и "позволяющих выполнить код с правами root" сразу создают впечатление будто это RCE.

    Кликбейт - это конечно хорошо, но очень не приятно, что после каждой подобной новости приходится самому лазить в первоисточники и проверять есть ли там RCE или это очередной LPE.

    Заранее спасибо.

     
     
  • 2.9, Дырик (?), 18:24, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    RCE, Cache poisoning, infoleak, infoleak, dos, infoleak
     
     
  • 3.11, ruroruro (ok), 18:34, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > RCE

    [citation needed]? На странице "Vulnerability Note VU#471747", на которую ссылается пост сказано только про LPE: "A local attacker may execute arbitrary code as root via DHCPv6 manipulation", "allows local attackers to execute arbitrary code with root privileges via a crafted DHCPv6 packet".

    Страничка самого CVE-2026-4892 на сайте NVD тоже классифицировано как "Attack Vector: Local".

    > Cache poisoning, infoleak, dos

    Остальное - вроде как верно.

     
     
  • 4.12, Дырик (?), 18:46, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да, действительно. Звучит странно в контексте DHCPv6-пакетов, но видимо так.
    Вот полное письмо: https://marc.info/?l=oss-security&m=177852314119822&w=2

    >[оверквотинг удален]
    >
    > Cache Poisoning / Redirection (CVE-2026-2291, CVE-2026-4893) Attackers
    > may overwrite cache entries or manipulate response routing, enabling the
    > silent redirection of users to malicious domains.
    >
    > Information Disclosure (CVE-2026-4891, CVE-2026-4893) Internal memory
    > and network information may be inadvertently exposed.
    >
    > Local Privilege Escalation (CVE-2026-4892) A local attacker may execute
    > arbitrary code as root via DHCPv6 manipulation.

     
     
  • 5.15, Аноним (36), 19:07, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >Local Privilege Escalation (CVE-2026-4892) A local attacker may execute
    > arbitrary code as root via DHCPv6 manipulation.

    А далее прочитать не судьба?
    "The likely attack vector is the local network, where an attacker can craft and send a DHCPv6 packet to the vulnerable server"
    Слово "local" в данном CVE употребляется в значении LAN = local network. Если выставить DHCPv6 наружу (WAN), то будет вполне себе RCE

     
     
  • 6.19, ruroruro (ok), 19:21, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Если выставить DHCPv6 наружу (WAN), то будет вполне себе RCE

    Мне казалось, что DHCP нельзя (ну или бессмысленно) "выставить наружу", потому что DHCPv6 и прочие multicast пакеты не пересылаются роутерами дальше локалки.

    Если действительно достаточно локальной сети, а не "аккаунт на машине", то получается что CVSS не правильный (должно быть Attack Vector: Adjacent, а не Local). Ну или все-таки есть ещё какая-то причина, почему они решили пометить эту уязвимость именно как AV:L. Возможно, там что-то ещё мешает использованию "по проводу". :shrug:

     
     
  • 7.43, Аноним83 (?), 20:42, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ставить наружу реально бессмысленно (хотя такие выставители у горе провайдеров часто ложат сегмент сети - роутер начинает выдавать адреса соседям чудо абонента и инет у них ломается), однако это не значит что из инета нельзя получать DHCP пакетов :)
     
  • 6.33, Дырик (?), 20:07, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Откуда вы взяли эту цитату? Я перед ответом зашел в калькулятор CVSS, чтобы освежить знания, думал, забыл чего, но нет, local это local machine.
     
     
  • 7.88, Аноним (92), 13:45, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Как локальный акк подсунет серверу состряпанный dhcp6 пакет, если сервер принимает их только из интерфейса локальной сетки? Код злоумышлиника выполнится на local machine, на котором крутится уязвимый dnsmasq, а пакет будет пущен из локальной сети.
     
  • 6.35, Дырик (?), 20:09, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ваша цитата Generated by OpenCVE AI on May 11, 2026 at 20:37 UTC., не соответствует действительности.
     
  • 2.13, Аноним (13), 18:49, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Еще было бы классно указывать сколько лет 822 с 822 у 822 щ 822 е 822 с ... большой текст свёрнут, показать
     
     
  • 3.30, Аноним83 (?), 19:52, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, и всё это время оно работало на миллионах инсталляций и никому не мешало :)

    Проект там сильно легаси, внутри по коду трудно ориентироватся и что то править.

    Я планировал его заменить на собственный DHCP4+DHCP6+RA сервер на C+LUA.
    DHCP4 у меня уже в принципе работает, там только на луа осталось расписать всю логику.
    DHCP6 примерно так же, но я не тестил работу, просто разбирает/собирает пакеты, в логику даже не начинал смотреть.
    RA даже не брался.
    А ещё вебгуй бы и прочие плюхи.
    Пора реально ИИ припрягать какакодить :)

     
     
  • 4.37, Аноним (37), 20:12, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Ага, и всё это время оно работало на миллионах инсталляций

    И?

    > и никому не мешало :)

    Конечно оно никому не мешало ломать чужие компы.
    Или у вас есть доказательство, что никто посторонний никуда не ходил?

    > Проект там сильно легаси, внутри по коду трудно ориентироватся и что то править.

    Там всего 35к строк кода.
    Просто если дом лепить из овна и палок, то качество получится соответствующее.

     
     
  • 5.41, Аноним83 (?), 20:40, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    И много наломали? Какой реальный ущерб?

    35к строк кода для такого проекта очень много.
    У меня даже с исходниками LUA (их вроде как 10к) получается меньше для сходного функционала.
    Примерно по 3к строк кода на DHCP4/DHCP6 реализацию протоколов и биндингов в луа ушло.
    Ещё наверное 5к остальной С код для сетей, потоков и пр.
    Дальше на луа логика компактная получается, относительно, там практически можно сказать что это конфиг и не считать за код :)

    DNS - ещё 1-2к строк кода.
    RA в пределах 3к.

    Итого где то 15к строк на С, ещё 5к можно для луа кода оставить.
    Если накинуть интерпретатор луа то со всеми натягами 30к получается, но функционала и гибкости на порядки больше влезет.

     
     
  • 6.45, Аноним (45), 20:53, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > И много наломали? Какой реальный ущерб?

    Думаю ущерб будут еще считать, и найдут взломы, которые непонятно как случились.
    Но это не важно, так как вам пофиг.

    > 35к строк кода для такого проекта очень много.
    > У меня даже с исходниками LUA (их вроде как 10к) получается меньше для сходного функционала.

    Ну так не сравнивайте ЯП высокого уровня и ассембрер-переросток)


     
     
  • 7.47, Аноним83 (?), 21:10, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Никто уже ничего не найдёт.

    Технически то луа тоже на С так что можно сказать что это С либа для парсинга конфига :)

     
  • 6.52, Аноним (20), 21:30, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    >И много наломали? Какой реальный ущерб?

    Как вы собираетесь это определять для нулевого дня? В этом та весь и смысл, даже если машину взломают, вы не поймёте как.
    >Дальше на луа логика компактная получается, относительно, там практически можно сказать что это конфиг и не считать за код :)

    Вот не могут сишники писать на си, обязательно надо луа вкорячить. Или питон или js.

     
     
  • 7.59, Аноним83 (?), 22:30, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Я вообще последнее время часто на shell script пишу, потому что задачи такие.
     
     
  • 8.74, Аноним (21), 08:06, 13/05/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 2.89, Аноним (92), 13:46, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Что уже начальство песочит, тыкая в статью? )
     

  • 1.8, Дырик (?), 18:22, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это только самая вершина айсберга. Кто приберёг все самое интересное для pwn2own, c 14 мая начнут сдавать баги, а далее просто начнут расчехлять всё ;)

    Серьезные уязвимости, на поиск которых требовались месяцы работы топовых специалистов, теперь может найти средненький специалист за дни-недели.

     
     
  • 2.18, Аноним (18), 19:19, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты говоришь об этом, как будто это что-то плохое!
     
  • 2.32, Аноним83 (?), 20:00, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну расчехлят, ну обновимся может быть, когда руки дойдут и что дальше?

    Уже даже в венде как то так научились делать чтобы черви не самоходили, а уж там то всегда была гомогенная среда, самая сладкая для такого.
    Вроде больше 5 лет прошло с последнего массового выгула самохода, если ничего не путают, а то и все 23 - там то уж точно самоходность была в полный рост :)

    Линукса и прочие - их всегда было мало и они все на друг друга не похожи - умучаешься самохода писать ради полутора калек.

     

  • 1.17, Аноним (17), 19:15, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://github.com/openwrt/openwrt/pull/23316
     
  • 1.23, Аноним (23), 19:37, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > позволяющее атакующему, имеющему доступ к локальной сети, выполнить код с правами root через отправку специально оформленного пакета DHCPv6

    то есть если в твоей квартирной сети есть телефон с максом то он угонит твой роутер с опенврт и установит на него бекдор от гебухи.

     
     
  • 2.31, Аноним83 (?), 19:54, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Увы но нет.
    В андройдах нет DHCP6 поддержки вообще, только RA.
    Удивительно что в RA реализации dnsmasq ничего не нашлось :)
     
     
  • 3.38, Аноним (-), 20:14, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В андроиде приложуха не может отправить UDP пакет? Там это, в браузере, QUIC/HTTP3 реализовано без поддержки со стороны системы.
     
     
  • 4.44, Аноним83 (?), 20:43, 12/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Это да, тут вы правы.
     
  • 2.64, Аноним (21), 00:12, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > телефон с максом

    Там пока прочухают, согласуют, все бумажки подпишуть... уже и все уязвимые роутеры помрут от рассохшихся конденсаторов.
    Слишком сложно.

     
     
  • 3.71, Аноним (66), 01:59, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не сложно. По методичке же начали детектить впны на девайсах у ло^w нормисов, могут и дальше пойти и начать сканить локалку такого девайса с малварью на борту.
     
     
  • 4.73, Аноним (21), 08:06, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Вот именно, по методичке. Которую спустили сверху.
     

  • 1.29, Zenitur (ok), 19:51, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ждём фикс во Freexian.
     
  • 1.34, Аноним (34), 20:09, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Проект Dnsmasq задействован в платформе Android

    Рутаем любую мобилу?

     
  • 1.46, жявамэн (ok), 21:06, 12/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    dnscrypt-proxy
    больше ничего не нужно
     
  • 1.72, runoverheads (ok), 04:10, 13/05/2026 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     
  • 1.76, Аноним (76), 08:50, 13/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Oblivious DoH ODoH разработана инженерами Apple и Cloudflare в 2020 году Уж... большой текст свёрнут, показать
     
     
  • 2.79, Аноним83 (?), 11:24, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Да да, за чей счёт содержатся те прокси и дох/дот сервера?
     
  • 2.87, Аноним (92), 13:29, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Кто сказал, что хозяин не общий? или Они могут просто "бартер" устроить и получить для двоих всю информацию о Вас.
     

  • 1.77, Аноним (77), 09:09, 13/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мне категорически не нравится идея сращивания dns с dhcp в одном демоне, именно в контексте того, что сабж часто используется во всяких штуках типа openwrt. Часто бывает нужно использовать разных форвардеров для разных компов в сети, чтобы при этом работала общая система имён в локальной сети. Да или просто резолвить домен в разные ip в зависимости от того, кто его запрашивает. С одним демоном и общим dns кэшем такого не сделать.
     
     
  • 2.78, Аноним (21), 10:39, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Часто бывает нужно использовать разных форвардеров для разных компов в сети
    > Да или просто резолвить домен в разные ip в зависимости от того, кто его запрашивает.
    > С одним демоном и общим dns кэшем такого не сделать.

    Чому не сделать? Blocky так умеет, Adguard Home, вроде бы, тоже... Да, это уже софт не для роутеров  (ну, или не для всех), но всё же.
    Последний и в DHCP умеет.

     
     
  • 3.80, Аноним (77), 11:25, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Часто нужен именно софт для роутеров, т.к. ребуется кормить "правильные" адреса устройствам, на которые невозможно установить софт, или отредактировать hosts, т.к. производитель не предусмотрел такое.
     
  • 3.84, Аноним (77), 11:36, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не нашёл нигде информации  о том, использует ли blocky отдельный кэш для разных групп, или кэш все-таки общий.
     
  • 2.82, Аноним83 (?), 11:30, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    dnsmasq для закрытия потребности сети в DHCP+DNS+TFTP.
    Странные конфиги - это действительно мимо.

    У меня вот не возникало никогда потребностей которые вы описываете.

     
  • 2.90, Аноним (92), 13:49, 13/05/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Не возникает фрагментации (расхождении) при развитие разных продуктов.
     

  • 1.85, Аноним (92), 13:15, 13/05/2026 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +/
     
  • 1.86, Аноним (92), 13:22, 13/05/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что-то forky в Debian отстает от других. Bookworm, trixie, sid уже устранили все описанные в статье уязвимости.
    https://security-tracker.debian.org/tracker/source-package/dnsmasq
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру