Podatności Eclipse Jetty

Kod obsługi wyjątków w Eclipse Jetty przed wersją 9.2.9.v20150224 umożliwia zdalnym atakującym uzyskanie wrażliwych informacji z pamięci procesu poprzez nielegalne znaki w nagłówku HTTP, znane jako JetLeak.

W Eclipse Jetty komponent uwierzytelniania Digest po stronie serwera używa ISO-8859-1 do kodowania hasła jako bajtów, co powoduje, że znaki spoza tego zestawu (np. chińskie, cyrylica, greckie) są zastępowane znakiem '?'.

W Eclipse Jetty klasa SessionAuthentication przechowuje poświadczenia uwierzytelniające w serializowalnym obiekcie. Gdy poświadczenia zawierają hasło w postaci jawnej, a uwierzytelniona sesja jest zapisywana w magazynie danych sesji, hasło może zostać zapisane w trwałym magazynie w postaci jawnej. Atakujący z wystarczającymi uprawnieniami do odczytu zapisanych danych sesji może uzyskać hasła w postaci jawnej uwierzytelnionych użytkowników.

W Eclipse Jetty, w różnych wersjach jetty-security i jetty-eeN-security, dwa lub więcej ograniczeń bezpieczeństwa z tym samym zestawem http-method-omission i bez wzorców URL nie są prawidłowo łączone zgodnie ze specyfikacją Jakarta Servlet. W rezultacie późniejsze zestawy http-method-omission nadpisują wcześniejsze ograniczenia z tym samym zestawem http-method-omission.

W Eclipse Jetty, w różnych wersjach jetty-server i jetty-proxy, biała/czarna lista hostów jest wrażliwa na wielkość liter, co pozwala na przepuszczenie hostów różniących się jedynie wielkością liter.

W Eclipse Jetty, w różnych wersjach jetty-security, jetty-eeN-security i jetty-eeN-servlet, ograniczenia specyfikacji Jakarta zdefiniowane jako http-method-omission mogą zostać obejść poprzez użycie podciągów zdefiniowanych metod HTTP.

W kliencie HttpClient biblioteki Jetty, gdy żądanie jest wysyłane przez serwer proxy, serwer może odpowiedzieć kodem 407 (wymagane uwierzytelnienie proxy). Klient błędnie interpretuje tę odpowiedź jako pochodzącą od proxy i ponownie wysyła żądanie z nagłówkiem Proxy-Authentication, który trafia do serwera, ujawniając mu poświadczenia proxy.

W Eclipse Jetty klient HttpClient może otrzymać przekierowanie w postaci /secure/../evil. Jeśli atakujący kontroluje przekierowania, HttpClient dopasowuje poświadczenia uwierzytelniające do ścieżki /secure zamiast znormalizować ją do /evil, przez co wysyła nagłówek Authorization dla /secure do /evil.

W Eclipse Jetty komponenty `TryPathsHandler` i `TryFilesFilter` mogą być skonfigurowane do przekazywania żądań do szablonowych URI, takich jak `index?p=$path`, gdzie `$path` to ścieżka żądania. Ścieżki URI mogą zawierać znaki zarezerwowane w zapytaniach URI, przez co ścieżka `/s&a=1` staje się `index?p=/s&a=1` i jest interpretowana jako dwa parametry zapytania (`p=/s` oraz `a=1`) zamiast jednego.

W Eclipse Jetty w różnych wersjach jetty-annotations i jetty-eeN-annotations reguły autorytatywnego wzorca URL dla mieszanego zastosowania adnotacji @ServletSecurity i ograniczenia security-constraint z web.xml na tym samym wzorcu URL nie były stosowane, gdy web.xml zawierał więcej niż jeden wzorzec URL dla serwletu, a ograniczenie dotyczyło tylko części z nich.

W Eclipse Jetty stwierdzono podatność polegającą na nieprawidłowym rozwiązywaniu ścieżek URI zawierających średniki. Żądanie do zasobu takiego jak '/public;/../admin/secret.txt' powoduje, że Jetty zwraca nierozwiązaną ścieżkę '/public/../admin/secret.txt' zamiast oczekiwanej '/admin/secret.txt'. Sam Jetty nie jest podatny na atak, ponieważ nie serwuje plików, które nie przejdą kontroli aliasów, ale aplikacje internetowe polegające na rozwiązywaniu ścieżek przez Jetty mogą być zdezorientowane.

W Eclipse Jetty dla żądań HTTP/1, HTTP/2 i HTTP/3 nie ma ścisłego sprawdzenia, czy autorytet żądania (host i port) jest zgodny z wartością nagłówka Host (jeśli jest obecny). Ta niezgodność może prowadzić do problemów takich jak błędne konstruowanie URI, wybór wirtualnego hosta, działanie reverse proxy, mylące logi i inne.

W Eclipse Jetty pierwsze żądanie HTTP/1.1 z nagłówkami końcowymi (trailers) powoduje, że serwer przechowuje te nagłówki dla kolejnych żądań na tym samym połączeniu. Kolejne żądania bez nagłówków końcowych raportują nagłówki z pierwszego żądania, a żądania z własnymi nagłówkami końcowymi raportują sumę nagłówków z pierwszego i bieżącego żądania.

Eclipse Jetty ma podatność na przemycanie żądań HTTP/1.1 (request smuggling) związaną z obsługą rozszerzeń chunk, gdzie parser kończy parsowanie rozszerzeń przy znaku \r\n wewnątrz cudzysłowów zamiast traktować to jako błąd.

W Eclipse Jetty klasa JASPIAuthenticator ustawia zmienne ThreadLocal podczas uwierzytelniania, ale nie czyści ich przy wczesnym powrocie. Kolejne żądanie na tym samym wątku dziedziczy te wartości, co prowadzi do złamania kontroli dostępu i eskalacji uprawnień.

W Eclipse Jetty w wersjach 12.0.0-12.0.31 i 12.1.0-12.0.5, klasa GzipHandler zawiera podatność na wyciek pamięci. Gdy przetwarzane jest skompresowane żądanie HTTP z nagłówkiem Content-Encoding: gzip, a odpowiedź nie jest kompresowana, mechanizm zwalniania obiektu Inflater JDK nie zostaje uruchomiony, co prowadzi do wycieku zasobów.