Podatności Apache Tomcat

W Apache Tomcat na Windows z włączonym enableCmdLineArguments, CGI Servlet jest podatny na zdalne wykonanie kodu z powodu błędu w przekazywaniu argumentów wiersza poleceń przez JRE.

W Apache Tomcat w wersjach 9.0.0.M1-9.0.11, 8.5.0-8.5.33 oraz 7.0.23-7.0.90 domyślny servlet przy przekierowaniu do katalogu (np. z '/foo' na '/foo/') mógł zostać zmuszony do wygenerowania przekierowania na dowolny URI wskazany przez atakującego przy użyciu specjalnie spreparowanego URL-a.

Domyślne ustawienia filtra CORS w Apache Tomcat w wersjach 9.0.0.M1-9.0.8, 8.5.0-8.5.31, 8.0.0.RC1-8.0.52 oraz 7.0.41-7.0.88 są niezabezpieczone i włączają opcję 'supportsCredentials' dla wszystkich źródeł. Oczekuje się, że użytkownicy skonfigurują filtr CORS odpowiednio do swojego środowiska zamiast używać konfiguracji domyślnej, dlatego większość użytkowników nie powinna być dotknięta tym problemem.

W Apache Tomcat w wersjach 9.0.0.M1-9.0.4, 8.5.0-8.5.27, 8.0.0.RC1-8.0.49 oraz 7.0.0-7.0.84 wzorzec URL "" (pusty ciąg) mapujący dokładnie na katalog główny kontekstu nie był prawidłowo obsługiwany w definicjach ograniczeń bezpieczeństwa, co powodowało ich ignorowanie i umożliwiało nieautoryzowanym użytkownikom dostęp do chronionych zasobów aplikacji.

W Apache Tomcat w wersjach 9.0.0.M1-9.0.4, 8.5.0-8.5.27, 8.0.0.RC1-8.0.49 oraz 7.0.0-7.0.84 ograniczenia bezpieczeństwa zdefiniowane przez adnotacje Servletów były stosowane dopiero po załadowaniu danego Servletu, co w zależności od kolejności ładowania mogło powodować, że część ograniczeń nie została zastosowana i odsłaniała zasoby nieuprawnionym użytkownikom.

Filtr CORS w Apache Tomcat 9.0.0.M1 do 9.0.0.M21, 8.5.0 do 8.5.15, 8.0.0.RC1 do 8.0.44 oraz 7.0.41 do 7.0.78 nie dodawał nagłówka HTTP Vary informującego, że odpowiedź zależy od Origin, co w niektórych przypadkach umożliwiało zatruwanie pamięci podręcznej po stronie klienta i serwera.

Złośliwa aplikacja webowa działająca na Apache Tomcat w wersjach od 6.0.0 do 9.0.0.M9 mogła obejść skonfigurowany SecurityManager poprzez manipulację parametrami konfiguracyjnymi dla serwletu JSP.

Implementacja ResourceLinkFactory w Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M9, 8.5.0 do 8.5.4, 8.0.0.RC1 do 8.0.36, 7.0.0 do 7.0.70 oraz 6.0.0 do 6.0.45 nie ograniczała dostępu aplikacji webowych do globalnych zasobów JNDI tylko do tych zasobów, które były wyraźnie powiązane z aplikacją. W związku z tym aplikacja webowa mogła uzyskać dostęp do dowolnego globalnego zasobu JNDI, niezależnie od tego, czy skonfigurowano wyraźny ResourceLink.

W Apache Tomcat, gdy skonfigurowany jest SecurityManager, mechanizm zastępowania właściwości systemowych w plikach konfiguracyjnych mógł zostać wykorzystany przez złośliwą aplikację webową do obejścia SecurityManagera i odczytania właściwości systemowych, które nie powinny być widoczne.

W Apache Tomcat w wersjach od 6.0.0 do 9.0.0.M9 wystąpiła podatność, która pozwalała złośliwej aplikacji webowej na ominięcie skonfigurowanego SecurityManagera za pomocą metody narzędziowej Tomcata dostępnej dla aplikacji webowych.

Implementacje Realm w Apache Tomcat w wersjach 9.0.0.M1 do 9.0.0.M9, 8.5.0 do 8.5.4, 8.0.0.RC1 do 8.0.36, 7.0.0 do 7.0.70 oraz 6.0.0 do 6.0.45 nie przetwarzały podanego hasła, jeśli podana nazwa użytkownika nie istniała. To umożliwiało atak czasowy w celu określenia prawidłowych nazw użytkowników. Należy zauważyć, że domyślna konfiguracja zawiera LockOutRealm, co utrudnia wykorzystanie tej podatności.

Apache Tomcat w wersjach 9.0.0.M1 do 9.0.0.M20, 8.5.0 do 8.5.14, 8.0.0.RC1 do 8.0.43 oraz 7.0.0 do 7.0.77 nie przetwarza statycznych stron błędów zgodnie z metodą GET, gdy wystąpi błąd. W zależności od oryginalnego żądania może to prowadzić do nieoczekiwanych rezultatów, w tym zastąpienia lub usunięcia niestandardowej strony błędu, jeśli DefaultServlet ma włączone zapisywanie.

W Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M18 oraz od 8.5.0 do 8.5.12 wystąpiła regresja w przetwarzaniu plików wysyłanych przez HTTP. Szybkie zakończenie przetwarzania mogło spowodować, że ten sam procesor został dodany do pamięci podręcznej procesorów dwukrotnie.

W Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M17, 8.5.0 do 8.5.11, 8.0.0.RC1 do 8.0.41 oraz 7.0.0 do 7.0.75 wystąpił problem z używaniem niewłaściwego obiektu fasady w niektórych wywołaniach do słuchaczy aplikacji. To umożliwiało nieufnym aplikacjom dostęp do obiektów żądania lub odpowiedzi, co mogło prowadzić do nieautoryzowanego dostępu do informacji innej aplikacji webowej.

Błąd w obsłudze żądań pipelined w Apache Tomcat powoduje utratę żądania, gdy przetwarzanie pliku send file dla poprzedniego żądania zostanie zakończone. Może to prowadzić do sytuacji, w której odpowiedzi są wysyłane dla niewłaściwych żądań.

Metoda setGlobalContext w Apache Tomcat 7.x przed 7.0.68, 8.x przed 8.0.31 i 9.x przed 9.0.0.M3 nie sprawdza, czy wywołujący ResourceLinkFactory.setGlobalContext są autoryzowani, co pozwala zdalnym uwierzytelnionym użytkownikom obejść ograniczenia SecurityManager i czytać lub zapisywać dowolne dane aplikacji albo powodować odmowę usługi.

Implementacja utrzymywania sesji w Apache Tomcat w wersjach 6.x przed 6.0.45, 7.x przed 7.0.68, 8.x przed 8.0.31 oraz 9.x przed 9.0.0.M2 niewłaściwie obsługuje atrybuty sesji. To pozwala zdalnym uwierzytelnionym użytkownikom na obejście zamierzonych ograniczeń SecurityManagera i wykonanie dowolnego kodu w kontekście uprzywilejowanym za pomocą aplikacji webowej, która umieszcza spreparowany obiekt w sesji.

Apache Tomcat w wersjach 6.x przed 6.0.45, 7.x przed 7.0.68, 8.x przed 8.0.31 i 9.x przed 9.0.0.M2 nie umieszcza org.apache.catalina.manager.StatusManagerServlet na liście RestrictedServlets.properties, co pozwala uwierzytelnionym zdalnym użytkownikom obejść ograniczenia SecurityManagera i odczytać dowolne żądania HTTP, a w konsekwencji poznać wartości identyfikatorów sesji.

W Apache Tomcat występuje podatność na atak typu session fixation, która dotyczy wersji 7.x przed 7.0.66, 8.x przed 8.0.30 oraz 9.x przed 9.0.0.M2. Problem pojawia się, gdy różne ustawienia sesji są używane w przypadku wdrożeń wielu wersji tej samej aplikacji webowej, co może umożliwić zdalnym atakującym przejęcie sesji użytkowników.

Komponent Mapper w Apache Tomcat w wersjach 6.x przed 6.0.45, 7.x przed 7.0.68, 8.x przed 8.0.30 i 9.x przed 9.0.0.M2 przetwarza przekierowania przed uwzględnieniem ograniczeń bezpieczeństwa i filtrów. Pozwala to zdalnym atakującym na określenie istnienia katalogu poprzez URL bez kończącego ukośnika.

Luka typu directory traversal w RequestUtil.java w Apache Tomcat 6.x przed 6.0.45, 7.x przed 7.0.65 i 8.x przed 8.0.27 pozwala zdalnym uwierzytelnionym użytkownikom na obejście ograniczeń SecurityManager i wyświetlenie katalogu nadrzędnego poprzez /.. w ścieżce używanej przez aplikację webową w wywołaniach getResource, getResourceAsStream lub getResourcePaths. Demonstrowano to na katalogu $CATALINA_BASE/webapps.

Implementacja Expression Language (EL) w Apache Tomcat 6.x przed 6.0.44, 7.x przed 7.0.58 i 8.x przed 8.0.16 nie uwzględnia należycie możliwości istnienia dostępnego interfejsu zaimplementowanego przez niedostępną klasę. Pozwala to atakującym na obejście mechanizmu ochrony SecurityManager poprzez aplikację internetową wykorzystującą nieprawidłowe uprawnienia podczas oceny EL.

Apache Tomcat w wersjach 6.x przed 6.0.44, 7.x przed 7.0.55 oraz 8.x przed 8.0.9 nieprawidłowo obsługuje sytuacje, w których odpowiedź HTTP jest wysyłana przed zakończeniem odczytu całego ciała żądania. To umożliwia zdalnym atakującym wywołanie odmowy usługi (zużycie wątków) poprzez serię nieudanych prób przesyłania plików.

Plik java/org/apache/coyote/http11/filters/ChunkedInputFilter.java w Apache Tomcat 6.x przed 6.0.42, 7.x przed 7.0.55 i 8.x przed 8.0.9 nieprawidłowo obsługuje próby kontynuowania odczytu danych po wystąpieniu błędu. Umożliwia to zdalnym atakującym przeprowadzanie ataków typu HTTP request smuggling lub powodowanie odmowy usługi poprzez strumieniowanie danych z nieprawidłowym kodowaniem chunked transfer coding.

Podatność nieograniczonego przesyłania plików w Apache Tomcat 7.x przed 7.0.40, w pewnych sytuacjach związanych z przestarzałym kodem java.io.File i niestandardową konfiguracją JMX, pozwala zdalnym atakującym na wykonanie dowolnego kodu poprzez przesłanie i dostęp do pliku JSP.

Apache Tomcat przed 6.0.40, 7.x przed 7.0.54 i 8.x przed 8.0.6 nie ogranicza odpowiednio class loadera dla parsera XML używanego z arkuszami XSLT, co pozwala zdalnym atakującym na odczyt dowolnych plików przez XXE lub pliki związane z innymi aplikacjami w jednej instancji Tomcat.

Przepełnienie liczby całkowitej w pliku java/org/apache/tomcat/util/buf/Ascii.java w Apache Tomcat przed 6.0.40, 7.x przed 7.0.53 i 8.x przed 8.0.4, gdy działa za odwrotnym proxy, pozwala zdalnym atakującym na przeprowadzanie ataków typu HTTP request smuggling poprzez spreparowany nagłówek Content-Length HTTP.

W Apache Tomcat przed 6.0.40, 7.x przed 7.0.53 i 8.x przed 8.0.4, domyślny serwlet (DefaultServlet) nie ogranicza odpowiednio arkuszy XSLT, co pozwala zdalnym atakującym na ominięcie ograniczeń security-manager i odczyt dowolnych plików przez XXE.

Przepełnienie liczby całkowitej w funkcji parseChunkHeader w pliku java/org/apache/coyote/http11/filters/ChunkedInputFilter.java w Apache Tomcat przed 6.0.40, 7.x przed 7.0.53 i 8.x przed 8.0.4 pozwala zdalnym atakującym na spowodowanie odmowy usługi (wyczerpanie zasobów) poprzez nieprawidłowy rozmiar chunka w kodowaniu chunked transfer coding żądania podczas strumieniowania danych.

Apache Tomcat przed wersjami 6.0.39, 7.0.50 i 8.0.0-RC10 pozwala atakującemu na uzyskanie informacji o wewnętrznych szczegółach Tomcata poprzez wykorzystanie niezaufanej aplikacji webowej zawierającej dokumenty XML (context.xml, web.xml, *.jspx, *.tagx, *.tld) z deklaracją encji zewnętrznej i odniesieniem do niej, co stanowi problem XML External Entity (XXE).

Apache Tomcat przed wersjami 6.0.39, 7.0.50 i 8.0.0-RC10 nieprawidłowo obsługuje kodowanie transferu chunked, nie radząc sobie z dużą ilością danych chunked lub białymi znakami w nagłówkach HTTP w polu trailer, co pozwala zdalnemu atakującemu na spowodowanie odmowy usługi poprzez strumieniowanie danych. Podatność istnieje z powodu niepełnej poprawki dla CVE-2012-3544.

Apache Tomcat przed wersją 6.0.39, 7.x przed 7.0.47 i 8.x przed 8.0.0-RC3, gdy używany jest konektor HTTP lub AJP, nieprawidłowo obsługuje pewne niespójne nagłówki żądań HTTP. Umożliwia to zdalnym atakującym wywołanie błędnej identyfikacji długości żądania i przeprowadzenie ataków typu request smuggling poprzez wiele nagłówków Content-Length lub nagłówek Content-Length i nagłówek "Transfer-Encoding: chunked".

Funkcja FormAuthenticator w Apache Tomcat 6.0.21 do 6.0.36 i 7.x przed 7.0.33 nieprawidłowo obsługuje relacje między wymaganiami uwierzytelniania a sesjami, co pozwala zdalnemu atakującemu na wstrzyknięcie żądania do sesji poprzez wysłanie tego żądania podczas kończenia formularza logowania. Jest to wariant ataku session fixation.

Apache Tomcat 6.x przed 6.0.37 i 7.x przed 7.0.30 nieprawidłowo obsługuje rozszerzenia chunk w kodowaniu transferu chunked. Umożliwia to zdalnym atakującym wywołanie odmowy usługi poprzez strumieniowanie danych.

Apache Tomcat 6.x przed 6.0.36 i 7.x przed 7.0.28 ma podatność w NioEndpoint.java, gdy konektor NIO jest używany z sendfile i HTTPS. Zdalny atakujący może spowodować nieskończoną pętlę (denial of service) przez przerwanie połączenia podczas odczytu odpowiedzi.

Funkcja CsrfPreventionFilter w Apache Tomcat 6.x przed 6.0.36 i 7.x przed 7.0.32 pozwala zdalnemu atakującemu na ominięcie mechanizmu ochrony przed Cross-Site Request Forgery (CSRF) poprzez wysłanie żądania bez identyfikatora sesji.

Apache Tomcat do wersji 7.0.x włącznie pozwala zdalnym atakującym wywołać odmowę usługi (awaria demona) poprzez częściowe żądania HTTP, co zademonstrowano atakiem Slowloris.

Implementacja HTTP Digest Access Authentication w Apache Tomcat 5.5.x przed 5.5.36, 6.x przed 6.0.36 i 7.x przed 7.0.30 nie sprawdza prawidłowo nieaktualnych wartości nonce w połączeniu z egzekwowaniem właściwych poświadczeń. Ułatwia to zdalnym atakującym obejście zamierzonych ograniczeń dostępu poprzez podsłuchiwanie sieci w celu uzyskania prawidłowych żądań.

Implementacja HTTP Digest Access Authentication w Apache Tomcat 5.5.x przed 5.5.36, 6.x przed 6.0.36 i 7.x przed 7.0.30 przechowuje informacje o uwierzytelnionym użytkowniku w stanie sesji, co ułatwia zdalnemu atakującemu ominięcie uwierzytelniania poprzez wektory związane z identyfikatorem sesji.

Mechanizm przeciwdziałania replay w implementacji HTTP Digest Access Authentication w Apache Tomcat 5.5.x przed 5.5.36, 6.x przed 6.0.36 i 7.x przed 7.0.30 śledzi wartości cnonce (client nonce) zamiast nonce (server nonce) i nc (nonce-count), co ułatwia zdalnemu atakującemu ominięcie ograniczeń dostępu poprzez podsłuchiwanie sieci w poszukiwaniu ważnych żądań. Jest to inna podatność niż CVE-2011-1184.

Niekompletne czyszczenie w Apache Tomcat może powodować sporadyczne błędy połączeń TLS 1.3. Podatność dotyczy wersji 11.0.0-M21 do 11.0.26, 10.1.25 do 10.1.60 oraz 9.0.90 do 9.0.122.

Niekompletne czyszczenie w Apache Tomcat pozwalało na wyciek informacji z nagłówka trailer z poprzedniego żądania do kolejnego żądania. Podatność dotyczy wersji 11.0.0-M23 do 11.0.26, 10.1.27 do 10.1.60 oraz 9.0.92 do 9.0.122.

Warunek wyścigu TOCTOU w Apache Tomcat podczas tworzenia gniazd domeny unix dla konektora APR/Native pozwala nieautoryzowanemu lokalnemu użytkownikowi na dostęp do gniazda domeny unix. Poprawka dla CVE-2026-65183 dotyczyła tylko konektora NIO. Podatność dotyczy wersji 9.0.47 do 9.0.122.

Podatność Execution After Redirect (EAR) w Apache Tomcat. Dotyczy wersji 11.0.0-M1 do 11.0.26, 10.1.0-M1 do 10.1.60 oraz 9.0.0.M1 do 9.0.122; znane są również wersje EOL 8.5.0-8.5.100 i 7.0.0-7.0.109.

Podatność "Failing Open" w Apache Tomcat: jeśli OpenSSLLifecycleListener jest skonfigurowany do trybu FIPS, ale aktywacja FIPS nie powiedzie się, Tomcat loguje błąd, ale kontynuuje pracę z JSSE w trybie nie-FIPS z podaną konfiguracją. Dotyczy wersji 11.0.0-M14 do 11.0.26, 10.1.22 do 10.1.60 oraz 9.0.92 do 9.0.122.

Nieprawidłowe obsłużenie niespójności parametru długości w Apache Tomcat umożliwia przemycanie wiadomości WebSocket, gdy używane jest per-message-deflate. Dotyczy wersji od 11.0.0-M1 do 11.0.25, od 10.1.0-M1 do 10.1.59, od 9.0.0.M1 do 9.0.121; znane są również wersje 8.5.0-8.5.100 i 7.0.56-7.0.109.

Podatność w Apache Tomcat powoduje utratę limitów czasu dla asynchronicznych zapisów WebSocket, co prowadzi do odmowy usługi (DoS). Problem dotyczy wielu wersji Tomcat, w tym 11.0.0-M1 do 11.0.25, 10.1.0-M1 do 10.1.59 oraz 9.0.0.M1 do 9.0.121.

Podatność w Apache Tomcat związana z niepełnym czyszczeniem zasobów może spowodować, że nieprawidłowo sformułowane żądanie (w zależności od czasu) doprowadzi do niepowodzenia jednego żądania od innego użytkownika. Dotyczy wersji 11.0.19-11.0.25, 10.1.53-10.1.59 oraz 9.0.116-9.0.121.

Podatność w Apache Tomcat polegająca na niekontrolowanym przydzielaniu zasobów umożliwia nieuwierzytelnionemu żądaniu AJP przypięcie wątku przetwarzania AJP, co prowadzi do odmowy usługi. Dotyczy wersji 11.0.0-M1-11.0.25, 10.1.0-M1-10.1.59 oraz 9.0.0.M1-9.0.121.

Podatność w Apache Tomcat polegająca na niekontrolowanym zużyciu zasobów podczas wysyłania komunikatu zamknięcia WebSocket umożliwia atak DoS. Dotyczy wersji 11.0.0-M5-11.0.25, 10.1.8-10.1.59 oraz 9.0.74-9.0.121.