Podatności Apache Tomcat

Podatność związana z niewłaściwym traktowaniem wielkości liter w LockOutRealm w Apache Tomcat może prowadzić do nieautoryzowanego dostępu. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, od 10.1.0-M1 do 10.1.54, od 9.0.0.M1 do 9.0.117, od 8.5.0 do 8.5.100 oraz od 7.0.0 do 7.0.109.

Podatność w Apache Tomcat związana z ujawnieniem nagłówka uwierzytelniania HTTP nieoczekiwanym hostom podczas uwierzytelniania WebSocket. Dotyczy wersji od 11.0.0-M1 do 11.0.21, 10.1.0-M1 do 10.1.54, 9.0.2 do 9.0.117, 8.5.24 do 8.5.100 oraz 7.0.83 do 7.0.109.

W Apache Tomcat występuje podatność związana z alokacją zasobów bez ograniczeń lub throttlingu. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, od 10.1.0-M1 do 10.1.54 oraz od 9.0.0.M1 do 9.0.117.

Podatność w Apache Tomcat związana z niewłaściwym zamykaniem lub zwalnianiem zasobów umożliwia atak typu 'made you reset'. Dotyczy to wersji od 11.0.0-M1 do 11.0.9, od 10.1.0-M1 do 10.1.43 oraz od 9.0.0.M1 do 9.0.107.

Implementacja HTTP/2 w Apache Tomcat od wersji 9.0.0.M1 do 9.0.0.M21 oraz od 8.5.0 do 8.5.15 omijała szereg zabezpieczeń, które zapobiegały atakom typu directory traversal. Możliwe było obejście ograniczeń bezpieczeństwa przy użyciu specjalnie skonstruowanego URL.

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.

Parser nagłówków HTTP/2 w Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M11 oraz od 8.5.0 do 8.5.6 wchodził w nieskończoną pętlę, gdy otrzymał nagłówek większy niż dostępny bufor. To umożliwiało przeprowadzenie ataku typu denial of service.

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.

Mechanizm stron błędów w specyfikacji Java Servlet wymaga, aby oryginalne żądanie i odpowiedź były przekazywane do strony błędu. W przypadku statycznych plików, oczekiwane zachowanie to obsługa treści pliku jak w przypadku żądania GET, co nie było realizowane w 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.

W Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M18 oraz od 8.5.0 do 8.5.12, obsługa ramki GOAWAY w protokole HTTP/2 nie zamykała strumieni związanych z połączeniem, które czekały na WINDOW_UPDATE, co mogło prowadzić do wyczerpania dostępnych wątków przetwarzania.

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ń.

Kod w Apache Tomcat w wersjach od 6.0.0 do 9.0.0.M11 pozwalał na parsowanie linii żądania HTTP z nieprawidłowymi znakami. Może to być wykorzystane w połączeniu z proxy, które również akceptuje te znaki, do wstrzykiwania danych do odpowiedzi HTTP.

Odkryto błąd programistyczny w przetwarzaniu żądań HTTPS w silniku serwletów i JSP Apache Tomcat, który może prowadzić do odmowy usługi z powodu nieskończonej pętli. Problem ten wynika z niepoprawnego przeniesienia poprawki CVE-2016-6816 bez uwzględnienia poprawki dla błędu Tomcat 57544.

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.

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.

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.

Nieprawidłowa autoryzacja w procesie uwierzytelniania FORM w Apache Tomcat pozwala na ominięcie ograniczenia bezpieczeństwa, które ogranicza użytkownikowi dostęp do zasobu dla metody POST, ale nie dla GET.

Obejście uwierzytelniania przez przechwycenie i powtórzenie w mechanizmie DIGEST w Apache Tomcat. Jeśli przed wykonaniem windowSize żądań klient wykona żądanie uwierzytelnione DIGEST z nonceCount na górnej granicy okna powtórzeń, to żądanie może być powtórzone tylko raz, dopóki nonceCount pozostaje w oknie.

Podatność na nieprawidłową walidację danych wejściowych w Apache Tomcat, wynikająca z niekompletnej poprawki dla CVE-2026-32990. Dotyczy wersji 11.0.20-11.0.24, 10.1.53-10.1.57 oraz 9.0.115-9.0.120.

Podatność dotycząca nieprawidłowej kontroli dostępu i autoryzacji w Apache Tomcat, prowadząca do obejścia ograniczeń bezpieczeństwa, jeśli ograniczenie dla dłuższej ścieżki jest zdefiniowane przed bardziej restrykcyjnym ograniczeniem dla krótszej pod-ścieżki. Dotyczy szerokiego zakresu wersji od 7.0.0 do 11.0.24.

W Apache Tomcat wykryto podatność związaną z niewystarczającą dokumentacją techniczną, która nie opisywała jasno wymagań bezpiecznej konfiguracji EncryptInterceptor. Problem dotyczy wielu wersji Tomcat od 7.0.100 do 11.0.23.

Podatność w mechanizmie przepisywania adresów URL (rewrite valve) Apache Tomcat umożliwia ominięcie ograniczeń bezpieczeństwa poprzez nieprawidłowe kodowanie szesnastkowe. Problem dotyczy wielu wersji Tomcat, w tym 11.0.0-M1 do 11.0.23, 10.1.0-M1 do 10.1.56, 9.0.0-M1 do 9.0.119 oraz 8.5.0 do 8.5.100.

Podatność w Apache Tomcat powoduje, że specjalne role i puste ograniczenia autoryzacji nie są uwzględniane podczas logowania efektywnego pliku web.xml. Problem dotyczy wersji od 11.0.0-M1 do 11.0.22, od 10.1.0-M1 do 10.1.55, od 9.0.0.M1 do 9.0.118 oraz od 8.5.0 do 8.5.100.

W Apache Tomcat wykryto podatność polegającą na braku reakcji na błąd podczas konfigurowania list CRL dla konektora opartego na FFM. Problem dotyczy wersji od 11.0.0-M1 do 11.0.22, od 10.1.0-M7 do 10.1.55 oraz od 9.0.83 do 9.0.118.

Podatność w mechanizmie uwierzytelniania typu digest w Apache Tomcat umożliwia obejście uwierzytelnienia. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, 10.1.0-M1 do 10.1.54, 9.0.0.M1 do 9.0.117, 8.5.0 do 8.5.100 oraz wersji przed 7.0.0.

Podatność związana z niewłaściwą walidacją danych wejściowych w Apache Tomcat może prowadzić do nieautoryzowanego dostępu lub manipulacji danymi. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, od 10.1.0-M1 do 10.1.54, od 9.0.0.M1 do 9.0.117 oraz od 10.0.0-M1 do 10.0.27.

Podatność typu Padding Oracle w domyślnej konfiguracji EncryptInterceptor w Apache Tomcat. Umożliwia atakującemu odszyfrowanie danych przesyłanych przez szyfrowany kanał.

Podatność typu 'Open Redirect' w funkcji uwierzytelniania FORM w Apache Tomcat umożliwia przekierowanie użytkowników na niezaufane strony. Dotyczy to wersji Apache Tomcat od 11.0.0-M1 do 11.0.0-M10, od 10.1.0-M1 do 10.0.12, od 9.0.0-M1 do 9.0.79 oraz od 8.5.0 do 8.5.92.

Jeśli aplikacja internetowa wysyła komunikat WebSocket jednocześnie z zamykaniem połączenia WebSocket podczas działania na Apache Tomcat 8.5.0 do 8.5.75 lub Apache Tomcat 9.0.0.M1 do 9.0.20, możliwe jest, że aplikacja będzie nadal używać gniazda po jego zamknięciu. Obsługa błędów wyzwolona w tym przypadku może spowodować umieszczenie obiektu z puli w puli dwukrotnie. Może to skutkować tym, że kolejne połączenia będą używać tego samego obiektu jednocześnie, co może prowadzić do zwrócenia danych niewłaściwemu użytkownikowi i/lub innych błędów.

Apache Tomcat w wersjach 10.0.0-M1 do 10.0.6, 9.0.0.M1 do 9.0.46 i 8.5.0 do 8.5.66 niepoprawnie parsował nagłówek transfer-encoding w niektórych sytuacjach, co umożliwia przemycanie żądań (request smuggling) w połączeniu z odwrotnym proxy. Tomcat ignorował nagłówek transfer-encoding, gdy klient deklarował akceptację tylko odpowiedzi HTTP/1.0, honorował kodowanie identity i nie zapewniał, że chunked encoding jest ostatnim kodowaniem.

Poprawka dla CVE-2020-9484 była niekompletna. Podczas korzystania z Apache Tomcat 10.0.0-M1 do 10.0.0, 9.0.0.M1 do 9.0.41, 8.5.0 do 8.5.61 lub 7.0.0 do 7.0.107 z konfiguracją, która była bardzo mało prawdopodobna do użycia, instancja Tomcat była nadal podatna na CVE-2020-9494. Należy zauważyć, że zarówno wcześniej opublikowane wymagania wstępne dla CVE-2020-9484, jak i wcześniej opublikowane środki łagodzące dla CVE-2020-9484 mają również zastosowanie do tego problemu.

Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0, 9.0.0.M1 do 9.0.41 oraz 8.5.0 do 8.5.61, podczas odpowiadania na nowe żądania połączeń h2c, może duplikować nagłówki żądań i ograniczoną ilość treści żądania z jednego żądania do drugiego, co oznacza, że użytkownik A i użytkownik B mogą widzieć wyniki żądania użytkownika A.

Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M9, 9.0.0.M1 do 9.0.39, 8.5.0 do 8.5.59 i 7.0.0 do 7.0.106 jest podatny na ujawnienie kodu źródłowego JSP w niektórych konfiguracjach, gdy serwuje zasoby z lokalizacji sieciowej na systemie plików NTFS. Przyczyną jest nieoczekiwane zachowanie metody File.getCanonicalPath() w JRE, spowodowane niespójnym zachowaniem API Windows (FindFirstFileW).

W Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M6, 9.0.0.M1 do 9.0.36, 8.5.0 do 8.5.56 i 7.0.27 do 7.0.104 długość ładunku w ramce WebSocket nie była poprawnie walidowana. Nieprawidłowe długości ładunku mogły wywołać nieskończoną pętlę, a wiele takich żądań mogło prowadzić do odmowy usługi.

W Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M6, 9.0.0.M5 do 9.0.36 i 8.5.1 do 8.5.56, bezpośrednie połączenie h2c nie zwalniało procesora HTTP/1.1 po przejściu na HTTP/2. Wystarczająca liczba takich żądań mogła spowodować OutOfMemoryException, prowadząc do odmowy usługi.

W Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M4, 9.0.0.M1 do 9.0.34, 8.5.0 do 8.5.54 i 7.0.0 do 7.0.103, jeśli atakujący może kontrolować zawartość i nazwę pliku na serwerze, a serwer jest skonfigurowany z PersistenceManager z FileStore i odpowiednimi filtrami, możliwe jest zdalne wykonanie kodu poprzez deserializację pliku.

Apache Tomcat w wersjach 9.0.28 do 9.0.30, 8.5.48 do 8.5.50 i 7.0.98 do 7.0.99 zawiera regresję, która powoduje nieprawidłowe przetwarzanie nieprawidłowych nagłówków Transfer-Encoding, co może umożliwić przemycanie żądań HTTP (request smuggling) w przypadku, gdy Tomcat znajduje się za odwrotnym proxy, które nieprawidłowo obsługuje te nagłówki.

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.

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.

Niewystarczające wygasanie sesji w Apache Tomcat: jeśli identyfikator sesji uwierzytelnionej sesji HTTP został zmieniony po ustanowieniu połączenia WebSocket w ramach tej sesji, sesja WebSocket nie została zamknięta po zakończeniu sesji HTTP, co narusza specyfikację Jakarta WebSocket.

Nieograniczona konsumpcja zasobów w Apache Tomcat przez wyciek alokacji w śledzeniu backlogu HTTP/2, gdy strumień jest resetowany.

Niewłaściwe uwierzytelnianie w Apache Tomcat: w niektórych okolicznościach (np. CLIENT-CERT, SPNEGO) użytkownik był uwierzytelniany, nawet jeśli nie istniał w DataSourceRealm.

Niewłaściwa autoryzacja w Apache Tomcat spowodowana nieprawidłowym użyciem definicji security-role-ref jako aliasów ról w Realm, oprócz poprawnego użycia z Request.isUserInRole().

Błąd off-by-one w Apache Tomcat wpływający na flagę [N] w zaworach przepisywania powoduje, że przetwarzanie przepisywania rozpoczyna się od drugiej reguły zamiast od pierwszej.

Podatność typu TOCTOU (Time-of-check Time-of-use) w Apache Tomcat podczas tworzenia gniazd domeny unix, umożliwiająca nieautoryzowanemu lokalnemu użytkownikowi dostęp do gniazda. Dotyczy wersji od 11.0.0-M1 do 11.0.24, od 10.1.0-M1 do 10.1.57 oraz od 9.0.42 do 9.0.120.

W Apache Tomcat w przykładowej aplikacji WebSocket występuje podatność na niekontrolowane zużycie zasobów. Problem dotyczy wersji 11.0.0-M20 do 11.0.24, 10.1.24 do 10.1.57 oraz 9.0.89 do 9.0.120.

W Apache Tomcat wykryto brak krytycznego kroku uwierzytelniania w JNDIRealm podczas korzystania z GSSAPI. Atakujący może uwierzytelnić się bez podania poprawnego hasła.