Когда говорят «баг живёт десятилетиями», обычно имеют в виду что-то малозаметное и глубоко закопанное. Но Squidbleed (CVE-2024-25617) — это не иголка в стоге сена. Это ржавый гвоздь, торчащий из бревна, на который кто-то 29 лет не обращал внимания.
Что за зверь. Squid — один из старейших HTTP-прокси и кэширующих серверов. Его используют провайдеры, корпоративные сети, образовательные учреждения. Он стоит на маршруте трафика и решает, что кэшировать, а что пускать дальше. И вот в этом «пускать дальше» и зарыта проблема.
Как работает уязвимость. Squid умеет пересылать HTTP-запросы на вышестоящий прокси (например, родительский кэш или upstream-сервер). Для этого он использует собственный протокол — Cache Digests или просто форвардинг по HTTP. Баг в том, что при определённых условиях (если включена опция `host_verify_strict` выключена или настроен сложный маршрут с SSL-терминацией) Squid может отправить оригинальный GET-запрос в открытом виде, игнорируя HTTPS-туннель. То есть: клиент думает, что он по HTTPS, а прокси сливает запрос plain-text’ом на upstream. Пароли, токены, cookies — всё как на ладони.
Кто под ударом. Любой, кто использует Squid в качестве forward proxy с цепочкой upstream-ов. Особенно опасно в конфигурациях с `cache_peer` и `ssl_bump`, когда трафик перехватывается и перенаправляется. Если ваш провайдер или корпоративный прокси не обновился — ваши данные могут гулять по магистралям без шифрования.
Статус. Баг закрыт в Squid 6.8 и 5.9. Но старые сборки (а их в продакшене — миллионы) продолжают работать. Это не zero-day, а скорее legacy-day: проблема была заложена в архитектуру ещё в 1996 году.
Итог. Squidbleed — хороший повод проверить, что у вас в сети не стоит древний прокси с открытым форвардингом. И напоминание: возраст софта — не синоним безопасности. Иногда 29-летний баг просто ждёт, когда кто-то внимательно посмотрит на исходники.
#Squidbleed #CVE_2024_25617 #HTTP #прокси #безопасность
