Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book

Nierozwiązana podatność w proxy squid dotycząca przetwarzania języka ESI

31 października 2024, 22:45 | W biegu | 0 komentarzy

ESI (Edge Side Includes) to prosty język pomocny przy dynamicznym składaniu treści strony internetowej, który został stworzony, aby rozwiązywać na urządzeniach brzegowych problemy związane ze skalowaniem infrastruktury. Tagi ESI są umieszczone w kodzie HTML i instruują procesor ESI, co powinien umieścić w finalnym kodzie strony.

Przykładowo:
<esi:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue"/>

spowoduje pobranie pierwszego URLa, a jeśli ten nie będzie działał – kolejnego. A jeśli i to się nie powiedzie, nie zostanie wykonana żadna operacja.

Tyle mówi Wikipedia w artykule o ESI. Dla omawianego dziś przypadku ważniejszy niż sposób działania ESI jest fakt, że wsparcie dla ESI posiada między innymi proxy squid.

TLDR:

  • CVE-2024-45802 (CVSS 7,5) w squid
  • dotyczy przetwarzania języka ESI
  • dla nowych wersji squid wsparcie ESI jest domyślnie wyłączone
  • na ten moment nie da się mieć bezpiecznej instalacji squida ze wsparciem ESI

Niestety, okazało się, że implementacja ESI w squid posiada wiele błędów. Znalazł je Joshua Rogers, który nie po raz pierwszy przyjrzał się temu popularnemu oprogramowaniu. Tym razem błędów jest mniej. W przypadku, gdy squid działa jako reverse proxy i posiada włączone podczas kompilacji wsparcie dla ESI, zaufany serwer może przeprowadzić atak DoS na proxy, skutkujący wyczerpaniem pamięci na serwerze. Skutki ataku dotyczą wszystkich domen obsługiwanych na proxy i wszystkich klientów.

Budowa ze wsparciem dla ESI była domyślna dla squid w wersji od 3.0 do 6.9, zmiana wartości domyślnej została dokonana dopiero w wersji 6.10.

Dla porządku dodajmy, że podatność otrzymała identyfikatora CVE-2024-45802 oraz poziom krytyczności wg CVSS 7,5.

Sprawdzenia, czy dana wersja squid jest podatna, można dokonać poprzez wydanie polecenia squid -v

Wersje 3.x, 4.x, 5.x, oraz 6.0 do 6.9 są podatne, jeśli w wyniku nie pojawi się tekst --disable-esi.

Wersja 6.10 i późniejsze domyślnie nie są podatne. Jeśli jednak w wyniku polecenia znajdzie się --enable-esi, oznaczać to będzie, że zostały zbudowane ze wsparciem dla ESI, a co za tym idzie są podatne.

Przykładowy wynik polecenia dla najnowszego stabilnego Debiana (12.7) i obecnej w nim wersji squid 5.7:

$ squid -v

Squid Cache: Version 5.7

Service Name: squid

Debian linux

configure options:  '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-option-checking' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' 'BUILDCXXFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/squid-5.7=. -fstack-protector-strong -Wformat -Werror=format-security -Wno-error=deprecated-declarations -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now ' 'BUILDCXX=g++' '--with-build-environment=default' '--enable-build-info=Debian linux' '--datadir=/usr/share/squid' '--sysconfdir=/etc/squid' '--libexecdir=/usr/lib/squid' '--mandir=/usr/share/man' '--enable-inline' '--disable-arch-native' '--enable-async-io=8' '--enable-storeio=ufs,aufs,diskd,rock' '--enable-removal-policies=lru,heap' '--enable-delay-pools' '--enable-cache-digests' '--enable-icap-client' '--enable-follow-x-forwarded-for' '--enable-auth-basic=DB,fake,getpwnam,LDAP,NCSA,PAM,POP3,RADIUS,SASL,SMB' '--enable-auth-digest=file,LDAP' '--enable-auth-negotiate=kerberos,wrapper' '--enable-auth-ntlm=fake,SMB_LM' '--enable-external-acl-helpers=file_userip,kerberos_ldap_group,LDAP_group,session,SQL_session,time_quota,unix_group,wbinfo_group' '--enable-security-cert-validators=fake' '--enable-storeid-rewrite-helpers=file' '--enable-url-rewrite-helpers=fake' '--enable-eui' '--enable-esi' '--enable-icmp' '--enable-zph-qos' '--enable-ecap' '--disable-translation' '--with-swapdir=/var/spool/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/run/squid.pid' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--with-systemd' '--with-gnutls' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/squid-5.7=. -fstack-protector-strong -Wformat -Werror=format-security -Wno-error=deprecated-declarations' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now ' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -ffile-prefix-map=/build/reproducible-path/squid-5.7=. -fstack-protector-strong -Wformat -Werror=format-security -Wno-error=deprecated-declarations'

Na ten moment podatność nie jest poprawiona – nie można mieć załatanego squida z jednoczesnym wsparciem ESI. Dla starszych wersji dostępne jest jedynie obejście problemu poprzez wyłączenie wsparcia dla ESI podczas kompilacji. Czyli dokładnie to ustawienie, które jest stosowane domyślnie w nowych wersjach squid.

~Paweł Różański

Spodobał Ci się wpis? Podziel się nim ze znajomymi:



Komentarze

Odpowiedz