Уязвимость класса ReDoS в NetworkManager означает, что специально сформированные данные — например, строка в конфигурации, имя сети или параметр, полученный извне — заставляют регулярное выражение внутри демона обрабатываться экспоненциально долго, из-за чего процесс NetworkManager нагружает процессор и сетевая подсистема фактически перестаёт отвечать. Проверить, затронута ли ваша система, можно командой nmcli --version и сверкой версии пакета с исправлениями в бюллетенях безопасности вашего дистрибутива.
Термин ReDoS (Regular Expression Denial of Service) расшифровывается как «отказ в обслуживании через регулярные выражения». Это не ошибка конфигурации пользователя, а дефект в коде: шаблон регулярного выражения составлен так, что на определённых входных данных движок совершает огромное количество возвратов (backtracking). Ниже разберём, как это работает применительно к NetworkManager, чем это опасно на сервере и на десктопе, и какие шаги стоит предпринять администратору.
Что такое ReDoS и почему он опасен
Классические регулярные выражения в большинстве движков (PCRE, POSIX) работают по принципу поиска с возвратом. Если шаблон содержит вложенные квантификаторы вида (a+)+ или пересекающиеся альтернативы, то на строке, которая «почти» совпадает с шаблоном, движок перебирает экспоненциально растущее число вариантов.
Для атакующего это готовый инструмент: достаточно подать на вход строку длиной в несколько десятков символов, чтобы вычисление заняло секунды или минуты процессорного времени. Поскольку NetworkManager работает с привилегиями root и обрабатывает данные, которые могут приходить из недоверенных источников (например, имена Wi-Fi сетей, параметры DHCP-ответов, данные из файлов конфигурации), зависание демона означает остановку управления сетью на всей машине.
Как ReDoS проявляется в NetworkManager
Конкретная точка входа зависит от версии и конкретной CVE: уязвимые шаблоны находились в разное время в парсерах конфигурации keyfile, обработке параметров соединений и компонентах, связанных с разбором строк. Общий сценарий выглядит так.
- 🔍 Вредоносная строка попадает в компонент, который валидирует её регулярным выражением.
- ⏳ Движок regex входит в катастрофический backtracking, процесс
NetworkManagerзанимает 100% одного ядра CPU. - 🔌 Команды
nmcliперестают отвечать, новые подключения не устанавливаются, существующие могут разорваться. - 🔁 После перезапуска службы через
systemctl restart NetworkManagerатака может повториться, если источник данных сохранился.
Отличить ReDoS от обычного сбоя помогает наблюдение за нагрузкой: если процесс NetworkManager стабильно держит высокий CPU без видимой причины и не реагирует на D-Bus-запросы, это характерный признак зависания в вычислительном цикле, а не сетевой неполадки.
Кто находится в зоне риска
Не каждая установка одинаково уязвима. Реальная эксплуатируемость зависит от того, может ли злоумышленник передать данные в уязвимый парсер. Если для конкретной CVE требуется локальный доступ или право изменять профили соединений, риск для типового десктопа заметно ниже, чем для многопользовательского сервера.
| Сценарий | Уровень риска | Комментарий |
|---|---|---|
| Домашний десктоп, один пользователь | Низкий | Нужен локальный доступ или вредоносная конфигурация |
| Многопользовательский сервер | Средний | Локальный пользователь может вызвать отказ сети для всех |
| Хост с недоверенными контейнерами/VM | Средний–высокий | Зависит от того, проброшено ли управление сетью |
| Точка доступа / роутер на Linux | Высокий | Внешние данные (SSID, DHCP) обрабатываются постоянно |
⚠️ Внимание: не пытайтесь проверять уязвимость «боевыми» PoC-строками на рабочей системе — успешный ReDoS оборвёт сетевые соединения, включая вашу SSH-сессию. Тестируйте только на изолированной виртуальной машине.
Как проверить версию и наличие исправления
Первый шаг — узнать установленную версию и сравнить её с данными бюллетеня безопасности вашего дистрибутива. Точные номера уязвимых и исправленных версий зависят от конкретной CVE и от того, как мейнтейнеры перенесли патч, поэтому сверяйтесь с официальными источниками: Debian Security Tracker, Ubuntu Security Notices, Red Hat CVE pages и аналогами.
nmcli --version
Debian/Ubuntu:
apt policy network-manager
RHEL/Fedora:
rpm -q NetworkManager
Если дистрибутив выпустил обновление, достаточно штатного апгрейда пакета. Важно: мейнтейнеры часто бэкпортируют исправление в старую ветку, поэтому номер версии сам по себе не всегда показателен — смотрите именно changelog пакета (apt changelog network-manager или rpm -q --changelog NetworkManager) на упоминание идентификатора CVE.
☑️ Проверка системы на ReDoS в NetworkManager
Обновление и смягчение последствий
Основная мера — установить обновлённый пакет. В Debian/Ubuntu это делается командой sudo apt update && sudo apt upgrade network-manager, в Fedora/RHEL — sudo dnf upgrade NetworkManager. После обновления перезапустите службу: sudo systemctl restart NetworkManager. Учтите, что перезапуск кратковременно разрывает активные соединения — на удалённом сервере планируйте это с запасным каналом доступа (консоль, IPMI, локальный терминал).
Если обновление пока невозможно, снизить риск помогают организационные меры: ограничить локальный доступ недоверенных пользователей, не принимать конфигурации соединений из непроверенных источников, настроить мониторинг аномальной загрузки CPU процессом NetworkManager с автоматическим перезапуском через systemd (директивы Restart= и ограничения ресурсов в unit-файле).
⚠️ Внимание: не отключайте NetworkManager и не переходите на ручную настройку сети только из-за одной CVE без оценки риска — для большинства систем своевременное обновление пакета полностью закрывает проблему, а самопальная замена создаёт новые точки отказа.
Как разработчики исправляют подобные уязвимости
Понимание механики исправления помогает оценивать подобные бюллетени в будущем. Типовые подходы такие.
- 🛠️ Переписывание опасного шаблона: устранение вложенных квантификаторов и неоднозначных альтернатив, из-за которых возникает backtracking.
- ⏱️ Введение ограничений: лимит длины входной строки до передачи в regex или таймаут на сопоставление, если движок это поддерживает.
- 🧩 Замена движка: переход на линейные по времени движки (например, RE2-подобные) там, где не нужны обратные ссылки.
- ✅ Добавление регрессионных тестов с «ядовитыми» строками, чтобы уязвимость не вернулась в следующих релизах.
Почему простая проверка длины строки не всегда спасает
Катастрофический backtracking зависит от структуры строки, а не только от её длины. Иногда достаточно 30–40 символов определённого вида, чтобы время обработки измерялось минутами. Поэтому надёжное исправление — это исправление самого шаблона или движка, а ограничение длины лишь снижает поверхность атаки.
Мониторинг и реагирование на инцидент
Если вы подозреваете, что система уже подверглась ReDoS-атаке, начните с диагностики, а не с перезагрузки. Снимите показания: top или ps aux | grep NetworkManager покажут загрузку CPU, журнал journalctl -u NetworkManager — последние события перед зависанием. Эти данные помогут понять, какая именно строка или событие вызвали проблему.
После перезапуска службы проверьте источники внешних данных: профили соединений в /etc/NetworkManager/system-connections/, недавно подключённые Wi-Fi сети, DHCP-опции, если у вас нестандартная сетевая среда. При подтверждённой атаке зафиксируйте инцидент по внутренним процедурам безопасности и убедитесь, что обновление установлено на всех затронутых хостах, а не только на пострадавшем.
Часто задаваемые вопросы
Что такое ReDoS простыми словами?
Это атака, при которой специально подобранная строка заставляет регулярное выражение работать экспоненциально долго. Программа «зависает» на обработке, хотя входные данные крошечные. Для сетевого демона это означает отказ в обслуживании всей сетевой подсистемы.
Можно ли эксплуатировать ReDoS в NetworkManager удалённо?
Зависит от конкретной CVE. Часть уязвимостей требует локального доступа или возможности изменить конфигурацию, другие потенциально срабатывают на внешних данных вроде параметров сети. Точный вектор указан в описании конкретной CVE и бюллетене дистрибутива — ориентируйтесь на него, а не на общие предположения.
Как понять, что NetworkManager завис именно из-за ReDoS?
Характерный признак — процесс NetworkManager удерживает около 100% одного ядра CPU, не отвечает на nmcli и не пишет новых записей в журнал. Подтвердить можно, проанализировав, какие данные обрабатывались перед зависанием, и сравнив версию пакета с уязвимыми версиями из бюллетеня.
Достаточно ли перезапустить службу, чтобы устранить проблему?
Перезапуск лишь снимает симптом: зависший процесс освобождает CPU, сеть восстанавливается. Но если вредоносные данные поступят снова, зависание повторится. Устраняется проблема только обновлением пакета до версии с исправленным регулярным выражением.
Нужно ли менять NetworkManager на другой сетевой менеджер из-за ReDoS?
Нет. Уязвимости класса ReDoS встречаются в самом разном ПО, и смена инструмента не гарантирует защиту. Рациональная стратегия — своевременные обновления безопасности и мониторинг, а не замена штатного компонента дистрибутива.