Разработчики популярного обратного прокси-сервера Traefik выпустили внеплановые обновления, закрывающие уязвимость высокой степени опасности в реализации HTTP-прокси по умолчанию. Проблема затрагивает все стабильные ветки продукта, начиная с версии 2.0, и позволяет неаутентифицированному злоумышленнику отравить HTTP-ответы для других клиентов, используя общий пул постоянных соединений (keep-alive). Патчи уже доступны в виде релизов v2.11.53, v3.6.24 и v3.7.9.
Детали уязвимости
Ошибка, зафиксированная в GitHub Security Advisory под идентификатором GHSA-3ccp-42pg-hgv6, связана с обработкой HTTP-метода CONNECT в режиме HTTP/2 или HTTP/3. Когда клиент открывает туннельный CONNECT-запрос, Traefik перенаправляет его - вместе с телом запроса - на вышестоящий сервер (upstream) через стандартный HTTP/1.1-транспорт. Если бэкенд отвечает на CONNECT не-2xx кодом (например, ошибкой) и при этом сохраняет keep-alive, но не сбрасывает оставшееся тело запроса, то десинхронизированное сокетное соединение возвращается в общий пул простаивающих соединений Traefik. После этого новый клиент, которому достанется то же соединение, может прочитать в ответе данные, подставленные атакующим. В результате злоумышленник способен выдать один сеанс за другой и, теоретически, получить доступ к аутентифицированному или приватному контенту другого пользователя.
Важно отметить, что опция экземпляра sanitizePath (включена по умолчанию) не является надёжной защитой: уязвимость проявляется на любых бэкендах, которые отвечают на CONNECT с keep-alive не-2xx статусом. Экспериментальная реализация FastProxy, напротив, не подвержена данной проблеме, поскольку использует иную логику управления соединениями.
Разработчики устранили уязвимость тремя основными способами: отложили пересылку тела CONNECT-запроса до момента, пока бэкенд не подтвердит приём туннеля; запретили возвращать CONNECT-соединения в общий пул простаивающих сокетов; а также полностью отбрасывают тело CONNECT-запроса на пути ForwardAuth. Все три меры предотвращают ситуацию, при которой десинхронизированное соединение может быть повторно использовано для другого клиента.
Уязвимость затронула Traefik версий до v2.11.52 включительно, а также релизы третьей мажорной ветки: v3.6.0 - v3.6.23 и v3.7.0 - v3.7.8. Всем пользователям, эксплуатирующим Traefik в качестве обратного прокси или API-шлюза, настоятельно рекомендуется обновить установки до указанных исправленных версий. Администраторам, которые временно не могут выполнить обновление, стоит рассмотреть перевод входящих подключений на FastProxy, если это допустимо архитектурно.
Согласно бюллетеню безопасности, степень опасности уязвимости оценена как высокая (High). Базовые метрики по шкале CVSS v4 демонстрируют атакующий вектор через сеть с низкой сложностью, без необходимости аутентификации и взаимодействия с пользователем. При этом воздействие на конфиденциальность и целостность последующих систем (то есть данных, которые злоумышленник может прочитать или изменить у другого клиента) расценивается как высокое, хотя на основную систему Traefik (конфиденциальность, целостность, доступность) прямого влияния нет. CVE для данной уязвимости пока не назначен.
Подобные ошибки управления соединениями в прокси-серверах и балансировщиках нагрузки уже неоднократно фиксировались в разных продуктах. Они относятся к классу CWE-444 (некорректный анализ HTTP-запросов, приводящий к смешиванию ответов). В случае с Traefik проблема усугубляется тем, что она затрагивает все типичные сценарии использования обратного прокси - передачу трафика на внутренние сервисы, авторизацию через ForwardAuth и работу с WebSocket через CONNECT. Разработчики продукта оперативно выпустили патчи, и теперь ответственность за их своевременную установку лежит на пользователях.
Ссылки
