Разбор заголовков HTTP-запросов в Squid позволяет обойти защиту и подменить содержимое веб-кэша

Squid

Squid - один из самых распространённых кэширующих прокси-серверов. Он стоит между пользователями и внешней сетью: ускоряет доступ к сайтам, фильтрует трафик, хранит копии страниц. Три уязвимости в нём, о которых проект сообщил 12 сентября 2026 года, позволяют обойти защитные механизмы, испортить данные и вызвать отказ в обслуживании. Исправления вышли в версии 7.7, а уязвимы все ветки начиная с 3.3.

Детали уязвимостей

Первая уязвимость связана с обработкой служебного заголовка Transfer-Encoding в HTTP/1.1. Этот заголовок описывает, как тело запроса разбито на части. Squid проверяет последовательность обработки некорректно и определяет границы запроса иначе, чем устройства перед ним. Расхождение открывает путь для подмены границ запросов: злоумышленник прячет одно обращение внутри другого. Промежуточный фильтр видит безобидный запрос, а прокси исполняет спрятанный. Проблема получила идентификатор CVE-2026-61642, проект оценивает её как высокую по своей шкале.

Провести такую атаку может доверенный клиент. Это либо пользователь, у которого уже есть право ходить через прокси, либо внутренний узел сети. Внешний периметр запрос не остановит, потому что формально тот выглядит корректным. Обойти удаётся и средства защиты, установленные между клиентом и Squid. Если перед прокси работает ещё один HTTP-кэш, последствия шире. Злоумышленник записывает произвольное содержимое по любому адресу и отдаёт его другим клиентам. Человек открывает знакомый сайт и получает страницу, подготовленную атакующим.

Второй дефект касается аутентификации по HTTP. Squid передаёт учётные данные клиента соседнему кэшу и копирует имя пользователя в буфер фиксированного размера. Проверки длины не хватает, поэтому слишком длинное имя выходит за границы и портит соседние данные в памяти. Так проявляется переполнение буфера. Уязвимость затрагивает только те конфигурации, где учётные данные пользователя уходят на родительский прокси. Проверить это администраторам несложно: в рекомендациях проекта приведена команда, которая показывает такие узлы в настройках. Ограничить длину имён можно правилом списка контроля доступа, а вместо пароля соседнего кэша подойдёт проверка по адресу источника. Исправление вошло в 7.7, отдельного идентификатора CVE у проблемы нет.

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

Прокси стоит на границе сети и видит запросы всех пользователей. Через него проходят внутренние адреса, данные сессий, обращения к внешним сайтам. Подмена кэша бьёт по каждому, кто пользуется этим сервером: поддельная страница выглядит для них как настоящая. Провайдеры, крупные предприятия и госсектор держат такие прокси годами и обновляют их редко. Ошибка в разборе HTTP-запросов даёт атакующему возможность обойти защиту, которую выстраивали вокруг прокси. Подмена границ запросов вдобавок плохо заметна: журналы фиксируют корректные обращения, а спрятанный запрос внутри них не виден. Риски здесь три - нарушение целостности данных, обход политики безопасности и удалённый отказ в обслуживании.

Обновление до 7.7 закрывает все три проблемы. Подмену границ запросов устранили раньше, в 7.6, двум переполнениям буфера нужна именно 7.7. Сборки от сторонних поставщиков обновляются отдельно, поэтому нужно следить за их бюллетенями. Для подмены границ обходных путей нет, помогает только установка исправленной версии. Для остальных двух уязвимостей временные меры есть, они описаны в рекомендациях проекта. О реальных атаках с использованием этих уязвимостей Squid не сообщает.

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

Ссылки

Комментарии: 0