Podatności Jetty

Klient może wysyłać specjalnie spreparowane żądania HTTP/1.1 chunked do serwera Jetty, które powodują, że Jetty i pośredniczący proxy interpretują różne granice żądań, co może prowadzić do przemycania żądań HTTP (HTTP request smuggling). Jest to spowodowane akceptowaniem przez Jetty pojedynczego znaku LF jako terminatora w częściach parsowania żądań chunked. W zależności od wersji Jetty i skonfigurowanego trybu zgodności HTTP może to wystąpić w rozszerzeniach chunk, terminacji danych chunk lub terminacji nagłówków trailer.

Klient może wysyłać żądania HTTP/2 do serwera Jetty, które powodują blokowanie zapisów, które nigdy nie są odblokowywane, co ostatecznie prowadzi do zablokowania wszystkich wątków i całkowitej niedostępności serwera. Jest to spowodowane warunkiem wyścigu w serwerze podczas obsługi ramek RST_STREAM i GOAWAY wysyłanych przez klienta. Warunek wyścigu "resetuje" HTTP2Flusher.terminated, wcześniej ustawiony na nie-null, do wartości null, co pozwala na enqueuing wpisów w flusher, które jednak nigdy nie zostaną przetworzone. Te nieprzetworzone wpisy to te, które miałyby odblokować zablokowane wątki.

Jetty w wersjach do 9.4.x jest podatny na atak wykorzystujący kanał czasowy w pliku util/security/Password.java, co ułatwia zdalnym atakującym uzyskanie dostępu poprzez obserwację czasu, jaki upływa przed odrzuceniem niepoprawnych haseł.

Klient może wysłać ramkę WebSocket z nieznanym kodem operacji i bardzo dużą zadeklarowaną długością ładunku, co powoduje, że Jetty próbuje zaalokować dużą ilość pamięci i potencjalnie wyczerpuje stertę JVM. Dzieje się tak, gdy włączona jest auto-fragmentacja, ponieważ nieznane kody operacji omijają normalne ograniczenia rozmiaru ramki, a alokacja ładunku następuje przed walidacją kodu operacji.