Świat IT stanął w obliczu niezwykłego odkrycia, które redefiniuje nasze dotychczasowe pojęcie o tym, jak poważne mogą być konsekwencje zarządzania długiem technologicznym. Badacze z firmy Calif.io, wspierani przez zaawansowany model sztucznej inteligencji Claude Mythos Preview firmy Anthropic, zidentyfikowali krytyczną lukę w oprogramowaniu serwera proxy Squid. Podatność, opisana na blogu Calif, ochrzczona mianem Squidbleed (oficjalnie zarejestrowana jako CVE-2026-47729), przetrwała w kodzie źródłowym niezauważona przez blisko 29 lat – od 1997 roku, czyli od czasów administracji Billa Clintona.
Squid to jeden z najpopularniejszych na świecie otwartoźródłowych serwerów proxy i pamięci podręcznej (web cache), wdrożony w milionach sieci korporacyjnych, akademickich oraz u dostawców usług internetowych na całym globie. Fakt, że podatność o charakterystyce zbliżonej do niesławnego Heartbleed pozostawała niewykryta przez niemal trzy dekady, rzuca nowe światło na ogólne bezpieczeństwo oprogramowania open-source oraz rewolucyjną rolę sztucznej inteligencji w procesach takich jak audytowanie kodu dziedziczonego (legacy code).
Anatomia podatności: Jak działa Squidbleed?
Mechanizm techniczny: Heap Over-read w parserze FTP
U podstaw błędu leży niepoprawna walidacja granic bufora w parserze protokołu FTP (File Transfer Protocol). Choć Squid kojarzony jest głównie z ruchem HTTP/HTTPS, posiada on wbudowaną natywną obsługę mapowania i parsowania list katalogów FTP, umożliwiając użytkownikom starszych systemów przeglądanie zasobów FTP za pośrednictwem interfejsu webowego.
Podczas przetwarzania struktury katalogów przesyłanej przez serwer FTP, mechanizm Squid nie weryfikuje poprawnie długości zwracanych ciągów znaków w stosunku do zaalokowanego bufora pamięci na stercie (heap). Powoduje to błąd typu heap over-read (odczyt poza wyznaczonymi granicami pamięci). Parser przekracza granicę bieżącego bufora i odczytuje sąsiadujące bloki pamięci RAM.
Wektor ataku i warunki konieczne do eksploatacji
Aby skutecznie przeprowadzić atak i wyssać dane z pamięci Squid, napastnik musi spełnić trzy kluczowe warunki:
- Dostęp do proxy: Atakujący musi mieć uprawnienia do wysyłania żądań przez podatny serwer Squid proxy (np. znajdować się wewnątrz tej samej sieci korporacyjnej lub korzystać z publicznego punktu Wi-Fi chronionego przez to proxy).
- Kontrola nad serwerem FTP: Napastnik musi uruchomić lub przejąć kontrolę nad zewnętrznym serwerem FTP, do którego serwer Squid spróbuje się zalogować przez port TCP 21.
- Wywołanie listowania: Atakujący wysyła przez proxy żądanie otwacia katalogu na swoim złośliwym serwerze FTP. W odpowiedzi serwer FTP przesyła odpowiednio spreparowaną, zniekształconą strukturę odpowiedzi listowania zasobów.
W momencie parsowania tej złośliwej odpowiedzi, Squid dokłada do wyniku zwracanego atakującemu fragmenty pamięci sterty. Ponieważ Squid działa jako proces jednowątkowy współdzielący pamięć dla wielu sesji, w pamięci tej znajdują się pozostałości po operacjach innych użytkowników proxy.
Ważne ograniczenie techniczne: Wyciek danych dotyczy wyłącznie ruchu nieszyfrowanego (czysty HTTP) oraz specyficznych środowisk enterprise, w których serwer Squid jest skonfigurowany do terminacji i inspekcji połączeń TLS (SSL Bumping). Klasyczny ruch HTTPS przekazywany jako przezroczyste tunele (za pomocą metody
CONNECT) pozostaje bezpieczny, gdyż Squid nie ma wglądu w jego niezaszyfrowaną zawartość.
Jaki jest efekt? W pamięci współdzielonej serwera proxy znajdują się nieoczyszczone zapytania HTTP innych użytkowników sieci. Atakujący może w ten sposób w pełni pasywnie i niewykrywalnie przejąć:
- Ciasteczka sesyjne i tokeny OAuth
- Klucze API (np. do AWS, Azure czy Google Cloud)
- Dane autoryzacyjne przesyłane otwartym tekstem (HTTP) lub w konfiguracjach z głęboką inspekcją TLS (SSL Bumping).
Model Mythos jako super-audytor kodu?
Odkrycie Squidbleed stanowi kamień milowy w kontekście zastosowania modeli LLM (Large Language Models) w inżynierii wstecznej i automatyzacji procesów SecOps. Przez 29 lat kod ten był wielokrotnie analizowany przez tradycyjne narzędzia do statycznej analizy kodu (SAST) oraz audytowany przez tysiące programistów open-source. Tradycyjne fuzzery i debuggery pomijały ten błąd, m.in. ze względu na specyficzną architekturę zarządzania pulami pamięci w Squid, która w przeszłości generowała liczne fałszywe alerty w narzędziach systemowych.
Dopiero model Claude Mythos Preview, analizując semantycznie i strukturalnie archaiczne moduły FTP w Squid, powiązał logicznie sposób mapowania struktur tekstowych z alokacją pamięci niskiego poziomu i wskazał precyzyjną ścieżkę eksploatacji. To dowodzi, że nowoczesna sztuczna inteligencja w cyberbezpieczeństwie zyskuje zdolność wykrywania głębokich, logicznych błędów pamięciowych, wykraczając daleko poza proste dopasowywanie znanych sygnatur podatności.
Skutki biznesowe: Kto jest najbardziej zagrożony?
Największe ryzyko dotyczy współdzielonych środowisk proxy (shared proxy environments). Należą do nich przede wszystkim:
- Infrastruktura korporacyjna: Gdzie tysiące pracowników kieruje ruch przez centralny klaster proxy, a zaawansowane systemy DLP (Data Loss Prevention) wykorzystują mechanizm inspekcji pakietów.
- Instytucje rządowe i edukacyjne: Często polegające na starszych architekturach sieciowych z otwartym protokołem HTTP dla systemów typu legacy.
- Dostawcy publicznych Hotspotów Wi-Fi: Gdzie anonimowi użytkownicy mogą łatwo wejść do sieci i odpytywać proxy w celu szpiegowania innych internautów.
Atakujący działający wewnątrz takiej sieci może w sposób całkowicie pasywny i niewykrywalny przejmować krytyczne tokeny uwierzytelniające OAuth, ciasteczka sesyjne administratorów, a nawet nagłówki autoryzacyjne z kluczami API (np. do środowisk chmurowych AWS/Azure), co otwiera drogę do natychmiastowej eskalacji uprawnień i głębokiej kompromitacji organizacji.
Jak sprawdzić i zabezpieczyć swoją infrastrukturę?
1. Natychmiastowa aktualizacja (Remediacja)
Społeczność Squid wydała oficjalne łatki bezpieczeństwa. Poprawka eliminująca błąd została zintegrowana w gałęzi rozwojowej Squid version 8 oraz przeniesiona do stabilnej wersji produkcyjnej Squid 7.6. Administratorzy powinni niezwłocznie wdrożyć najnowsze pakiety dostarczone przez dystrybucje Linux (Ubuntu, Debian, RHEL) lub przeprowadzić samodzielną kompilację oprogramowania ze źródeł z oficjalnym patchem.
2. Tymczasowe wyłączenie protokołu FTP (zalecany Workaround)
Jeśli natychmiastowa aktualizacja systemu nie jest możliwa ze względów operacyjnych, ryzyko można zredukować do zera poprzez odpowiednią zmianę konfiguracji bezpieczeństwa sieci firmowej i całkowite zablokowanie obsługi protokołu FTP w pliku squid.conf. Ponieważ współczesny internet opiera się niemal w 100% na protokołach HTTP/HTTPS, wyczenie FTP nie wpłynie negatywnie na większość użytkowników biznesowych.
Aby wyłączyć obsługę FTP, upewnij się, że w konfiguracji zablokowano porty FTP oraz wyłączono powiązane listy kontroli dostępu (ACL):
# Przykładowe bezpieczne wyłączenie obsługi FTP w squid.conf
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
# Usuń lub zakomentuj port 21 (FTP):
# acl Safe_ports port 21 # ftp
# Całkowite zablokowanie ruchu do protokołu FTP
acl ftp_proto proto ftp
http_access deny ftp_proto
Krwawy koktajl podatności: Od Bleeding LLama i Squidbleed do… Krwawej Mary
Nomenklatura współczesnych błędów bezpieczeństwa staje się coraz bardziej „krwawa”. Niedawno na łamach naszego bloga szczegółowo analizowałam inne krytyczne zagrożenie, które uderzyło bezpośrednio w ekosystem sztucznej inteligencji – zobacz mój wpis na temat Bleeding Llama: Krytyczna luka RCE w Ollama (CVE-2026-7482).
Patrząc na to, jak najpierw drżeliśmy przed Heartbleed, potem przed luką w modelach open-source Ollama, a teraz przed Squidbleed, można odnieść wrażenie, że do pełnego kompletu w tym makabrycznym menu brakuje nam już tylko… dobrego drinka.
Skoro jako administratorzy sieci i inżynierowie SecOps musimy gasić tak spektakularne pożary w infrastrukturze legacy, po udanym załataniu systemów należy nam się chwila relaksu. Oto klasyczny, sprawdzony przepis na Krwawą Mary (Bloody Mary) – idealny koktajl na wieczór po ciężkim dniu zmagania się z podatnościami pamięci sterty.
Składniki
- 50 ml czystej wódki
- 120 ml gęstego soku pomidorowego
- 15 ml świeżo wyciśniętego soku z cytryny
- 2-3 krople sosu Worcestershire
- 2-3 krople sosu Tabasco (dodaj więcej kropel, jeśli luka w Twojej sieci miała wysokie CVSS 😉)
- Szczypta soli morskiej oraz świeżo mielonego czarnego pieprzu
- Kostki lodu
- Gałązka selera naciowego i plasterek cytryny do dekoracji
Przygotowanie
- Do wysokiej szklanki (typu highball) wrzuć kilka dużych kostek lodu.
- Wlej wódkę, sok pomidorowy oraz świeży sok z cytryny.
- Dodaj sos Worcestershire, Tabasco oraz dopraw szczyptą soli i pieprzu.
- Całość delikatnie wymieszaj za pomocą długiej łyżki barmańskiej (nie wstrząsaj w shakerze, aby sok zachował swoją aksamitną strukturę).
- Udekoruj szklankę gałązką selera naciowego, która idealnie komponuje się z pikantnym smakiem napoju. Twój koktajl ratunkowy jest gotowy!
OSTRZEŻENIE!
Nie dajcie się wpuścić w maliny, tak jak ja. W sieci polecana jest strona squidbleed<DOT>xyz. Okazuje się, że to jest crypto scam. Nie używajcie jej.
Gynvael, dzięki za heads up 🙂 Na x.com o tej stronie pisze Calif.
https://x.com/calif_io/status/2069399902342508951
https://x.com/calif_io/status/2069791993467990383
Podsumowanie: Przyszłość bezpieczeństwa w erze agentów AI
Przypadek Squidbleed i modelu Mythos uczy nas, że stabilność i wiek oprogramowania open-source nie są gwarantem jego bezwzględnego bezpieczeństwa. Pokazuje również, że granica między tradycyjnymi cyberzagrożeniami a nową erą automatyzacji sterowanej przez AI staje się płynna. Z jednej strony sztuczna inteligencja pozwala na błyskawiczne odnajdywanie historycznych błędów i ich łatanie, z drugiej – daje napastnikom potężne narzędzie do automatycznego generowania exploitów na masową skalę. Audytowanie kodu dziedziczonego przy użyciu zaawansowanych modeli LLM powinno stać się stałym elementem każdej nowoczesnej strategii cyberbezpieczeństwa w firmie.
