Обновление Squid Proxy закрывает 29-летнюю уязвимость утечки данных

Squid

Разработчики Squid Proxy выпустили патч, исправляющий уязвимость CVE-2026-47729, получившую неофициальное название "Squidbleed". Проблема затрагивает кодовую базу, сформировавшуюся ещё в 1997 году, и позволяет злоумышленнику извлекать из памяти прокси-сервера чувствительную информацию, включая HTTP-заголовки авторизации и ключи API. Уязвимость связана с некорректной обработкой FTP-протокола, который остаётся включённым в Squid по умолчанию, несмотря на своё фактическое устаревание.

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

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

Корень проблемы - ошибка в парсере FTP-списков каталогов Squid. При обработке каталогов с отсутствующим именем файла после временной метки парсер не проверяет корректно достижение конца строки. Функция стандартной библиотеки C "strchr()", используемая для поиска символов, при передаче ей нулевого терминатора (символа с кодом "\0") не возвращает NULL, как это могло бы ожидаться, а указывает на сам терминатор. В результате цикл продолжает считывать данные за пределами выделенного буфера, переходя в соседние области оперативной памяти. Это классический выход за границы буфера (heap buffer overflow).

Особую опасность уязвимости придаёт архитектура управления памятью в Squid. Сервер использует фиксированные пулы памяти (как правило, буферы размером 4 КБ), которые не очищаются при повторном использовании. Это означает, что данные от предыдущих сессий - например, содержимое HTTP-запросов - могут оставаться в памяти после освобождения. Когда уязвимый парсер FTP считывает данные за пределами своего буфера, он непреднамеренно захватывает эти фрагменты, которые затем отправляются атакующему в составе ответа.

В сценарии эксплуатации, описанном исследователями, злоумышленнику достаточно контролировать FTP-сервер, доступный для уязвимого экземпляра Squid. С помощью специально сформированных списков каталогов и многократного повторения запросов он может извлекать фрагменты памяти, ассоциированные с сессиями других пользователей. Потенциально в зону утечки попадают чувствительные HTTP-заголовки - токены авторизации, куки, ключи API. Особенно высок риск в средах, где Squid обрабатывает незашифрованный HTTP-трафик или выполняет перехват TLS (SSL-инспекцию). Хотя в современных условиях большая часть HTTPS-трафика передаётся через метод CONNECT и не анализируется Squid напрямую, корпоративные системы с активной инспекцией SSL остаются уязвимыми.

Кроме того, если Squid развёрнут в общей среде - например, в многопользовательской сети или на публичной Wi-Fi-точке доступа - вероятность раскрытия данных между сессиями разных пользователей значительно возрастает. Это превращает уязвимость в серьёзную угрозу для конфиденциальности в коллективных инфраструктурах.

Разработчики Squid выпустили патч, который вносит простое, но эффективное исправление: в коде теперь выполняется явная проверка на нулевой терминатор перед вызовом "strchr()", что предотвращает выход указателя за границу строки. Исследователи также отмечают, что именно такие долгоживущие ошибки в зрелых проектах с открытым исходным кодом демонстрируют риск накопления технического долга. Мелкие детали реализации, незамеченные при первоначальной разработке, способны десятилетиями ждать своего часа.

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

Ссылки

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