Обработка подтверждений в OpenVPN переполняет таймер и вызывает отказ в обслуживании

В OpenVPN, популярном средстве организации виртуальных частных сетей (VPN), найдена уязвимость, связанная с обработкой подтверждающих пакетов в канале управления. Она позволяет удалённому злоумышленнику без аутентификации вызвать отказ в обслуживании. VPN-соединение не установится или будет разрываться уже после подключения. Затронуты все версии до 2.6.22 включительно, а также до 2.7.6 включительно. Исправление доступно в версии 2.7.7.

Уязвимость CVE-2026-84732

Проблема зарегистрирована как CVE-2026-84732. Производитель относит её к категории CWE-190, описывающей переполнение целочисленного значения. Такая классификация указывает на ошибку в арифметике таймера, а не на дефект криптографического протокола. Поскольку для атаки не требуется учётная запись, уязвимость заслуживает внимания администраторов всех OpenVPN-серверов.

OpenVPN применяется очень широко. Его ставят на серверы в офисах и центрах обработки данных, на клиентские ноутбуки и встроенное оборудование, включая маршрутизаторы и межсетевые экраны. Помимо самостоятельного использования, OpenVPN встроен во многие коммерческие продукты и облачные сервисы. Поэтому уязвимость потенциально затрагивает большое количество систем. Для компаний особенно чувствителен сценарий, при котором атака выводит из строя VPN-сервер. Удалённые сотрудники перестают получать доступ к внутренним ресурсам, а восстановление соединения может затянуться.

Чтобы понять суть проблемы, нужно вспомнить архитектуру OpenVPN. Программа устанавливает два логических канала. По первому передаётся шифрованный пользовательский трафик. Второй, контрольный, используется для служебного обмена. Здесь стороны согласуют параметры, проходят аутентификацию и обмениваются ключами. Контрольный канал работает на основе протокола TLS, который защищает служебные сообщения от подслушивания и подмены. Однако TLS не компенсирует ошибки в прикладной логике. Без успешного завершения работы контрольного канала туннель для данных не создаётся.

Надёжная доставка служебных сообщений обеспечивается специальным механизмом. Получив пакет, сторона отправляет подтверждение. Если подтверждение не приходит, отправитель считает пакет потерянным и повторяет передачу через интервал, заданный таймером. Такой подход гарантирует, что управляющие сообщения не пропадут из-за сетевых сбоев. Он применяется на уровне, который принято называть уровнем надёжности. Именно этот компонент и содержит ошибку.

Согласно бюллетеню, атакующий может вызывать либо неограниченный рост таймера повторной передачи, либо отправлять подтверждения для пакетов, которые не находятся в процессе передачи. Оба сценария приводят к переполнению целочисленного значения таймера. После этого механизм работает некорректно. Контрольный канал перестаёт отвечать на запросы или ожидает ответа бесконечно долго. Обмен служебными сообщениями прекращается, поэтому новая сессия не начинается, а текущая может оборваться. Поскольку все режимы OpenVPN используют контрольный канал для установки соединения, проблема проявляется независимо от конфигурации и типа аутентификации.

Для пользователя такие сбои выглядят как ошибка подключения или бесконечное ожидание при запуске VPN. Для администратора это означает множество жалоб и необходимость перезапускать сервис вручную. При этом шифрование данных работает исправно, что затрудняет диагностику. Атака может выглядеть как обычный сетевой сбой, поскольку видимых следов взлома не остаётся. Технические подробности эксплуатации не раскрыты, но это типично для уязвимостей, описанных до выхода исправления.

Важная особенность уязвимости - отсутствие необходимости в аутентификации. Злоумышленнику достаточно отправить на сетевой порт несколько специально созданных пакетов. Публичные серверы, доступные из интернета, находятся в зоне наибольшего риска. Адрес и порт такого сервера обычно известны или легко обнаруживаются. Клиентские устройства атаке подвержены меньше, однако она возможна, если пользователь подключается к заведомо вредоносному или скомпрометированному серверу. В таких случаях атакующему достаточно контролировать серверную сторону соединения.

Об ошибке сообщил Марк Брегман из компании Fox-IT. Разработчики внесли исправление в версию 2.7.7. Пользователям затронутых версий следует как можно быстрее обновить ПО. Если OpenVPN получен из репозитория операционной системы, нужно дождаться обновлённого пакета или установить официальную сборку с сайта проекта. В организациях с несколькими серверами обновление лучше проводить поэтапно. Сначала стоит установить версию 2.7.7 на тестовый контур и проверить совместимость с текущей конфигурацией. После этого можно переходить на боевые серверы. Перед обновлением необходимо сохранить копии конфигурационных файлов, сертификатов и ключей, чтобы при необходимости быстро откатить изменения.

В качестве временной меры можно ограничить доступ к порту OpenVPN по IP-адресам. Для этого подойдут правила межсетевого экрана или настройки самого сервера. Например, разрешить подключения только с адресов, которые реально используются сотрудниками или филиалами. Это не устраняет уязвимость, но снижает вероятность атаки со стороны посторонних. Также стоит обратить внимание на системы мониторинга, чтобы заметить необычные всплески трафика к VPN-серверу.

На момент публикации не известно о реальных атаках с использованием CVE-2026-84732. Однако с выходом исправления информация об ошибке стала общедоступной. Это повышает риск появления эксплойтов (вредоносных программ, эксплуатирующих уязвимость), поэтому откладывать обновление не стоит. Кроме того, проблему нужно учитывать при планировании обслуживания VPN-инфраструктуры.

Устойчивость VPN зависит не только от криптографии. Ошибки во вспомогательных механизмах могут оказаться не менее опасными, чем дефекты алгоритмов шифрования. Регулярное обновление остаётся ключевой мерой защиты, и уязвимости вроде CVE-2026-84732 подтверждают это правило.

Уязвимость CVE-2026-84732

Ссылки