Podatności Netty

Netty, asynchroniczny framework aplikacji sieciowych, ma problem w wersjach od 4.2.0.Final do 4.2.13.Final, gdzie transport epoll nie wykrywa i nie zamyka połączeń TCP, które otrzymują RST po częściowym zamknięciu. To prowadzi do nieaktualnych kanałów, które nigdy nie są usuwane oraz w niektórych ścieżkach kodu do 100% obciążenia CPU w wątku pętli zdarzeń.

W Netty w wersjach 4.0.x przed 4.0.37.Final oraz 4.1.x przed 4.1.1.Final występuje podatność w pliku OpenSslEngine.java, która pozwala zdalnym atakującym na spowodowanie odmowy usługi poprzez nieskończoną pętlę.

Netty to asynchroniczny, sterowany zdarzeniami framework do tworzenia aplikacji sieciowych. Przed wersjami 4.1.137.Final i 4.2.17.Final funkcja io.netty.handler.ssl.SslClientHelloHandler#decode sprawdza niewłaściwy offset przed odczytaniem czterobajtowego nagłówka TLS handshake, więc ClientHello, którego nagłówek handshake obejmuje wiele rekordów, może spowodować IndexOutOfBoundsException i wywołać select(ctx, null). To wybiera domyślny SslContext zamiast kontekstu specyficznego dla SNI. We wdrożeniach, gdzie per-SNI clientAuth=REQUIRE jest jedyną bramą wzajemnego TLS, a domyślny SslContext używa clientAuth=NONE lub clientAuth=OPTIONAL i nie ma weryfikacji certyfikatów na poziomie aplikacji, nieuwierzytelniony zdalny atakujący może ominąć wymóg wzajemnego TLS chronionej trasy. Problem jest naprawiony w wersjach 4.1.137.Final i 4.2.17.Final.

Netty w wersjach 4.2.0.Final do 4.2.15.Final oraz 4.1.0.Final do 4.1.135.Final zawiera podatność w XmlDecoder, gdzie dostarczenie danych XML z deklaracją DOCTYPE do AsyncXMLInputFactory bez konfiguracji bezpieczeństwa może aktywować obsługę DTD i encji, stwarzając ryzyko XML External Entity (XXE).

Netty (io.netty:netty-codec-http2) przed wersją 4.1.61.Final zawiera podatność umożliwiającą przemycanie żądań (request smuggling). Nagłówek content-length nie jest poprawnie walidowany, gdy żądanie używa pojedynczego Http2HeaderFrame z ustawionym endStream na true. Może to prowadzić do przemycania żądań, jeśli żądanie jest proxy do zdalnego peera i tłumaczone na HTTP/1.1. Jest to kontynuacja GHSA-wm47-8v5p-wjpj/CVE-2021-21295, która nie naprawiła tego przypadku. Naprawiono w wersji 4.1.61.Final.

Netty (io.netty:netty-codec-http2) przed wersją 4.1.60.Final zawiera podatność umożliwiającą przemycanie żądań (request smuggling). Gdy żądanie HTTP/2 jest konwertowane do HTTP/1.1 przez `Http2StreamFrameToHttpObjectCodec` i przekazywane do zdalnego serwera, nagłówek Content-Length nie jest walidowany przez `Http2MultiplexHandler`, co pozwala atakującemu na osadzenie dodatkowych żądań w treści.

HttpObjectDecoder.java w Netty przed wersją 4.1.44 pozwala na wystąpienie nagłówka Content-Length wraz z drugim nagłówkiem Content-Length lub nagłówkiem Transfer-Encoding, co może prowadzić do nieprawidłowego przetwarzania żądań HTTP.

W pliku HttpObjectDecoder.java w bibliotece Netty przed wersją 4.1.44 nagłówek HTTP pozbawiony dwukropka może zostać zinterpretowany jako osobny nagłówek o nieprawidłowej składni lub jako "invalid fold". Może to prowadzić do błędnej interpretacji żądań HTTP.

Netty w wersjach przed 4.1.42.Final nieprawidłowo obsługuje białe znaki przed dwukropkiem w nagłówkach HTTP (np. w linii "Transfer-Encoding : chunked"). Prowadzi to do przemytu żądań HTTP (HTTP request smuggling).

Netty HttpServerCodec do wersji 4.2.17.Final i 4.1.137.Final niepoprawnie paruje odpowiedzi z żądaniami przy pipeliningu HTTP/1.1 z nagłówkiem Expect: 100-continue, co prowadzi do rozdzielania odpowiedzi i niebezpiecznego ponownego użycia połączenia.

Netty w wersjach od 4.2.11.Final do 4.2.18.Final ma niekompletną weryfikację nazwy hosta w ścieżce certyfikacji QUIC przy użyciu zwykłego X509TrustManager, co pozwala atakującemu na przedstawienie certyfikatu dla niewłaściwej nazwy hosta.

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.2.Final do 4.2.17.Final buduje pseudo-nagłówek :authority na podstawie nagłówka Host, ignorując nadrzędność authority z absolute-form request-target, co prowadzi do konfuzji autorytetu.

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.2.Final do 4.2.17.Final nie obsługuje specjalnie metody CONNECT z formą authority-form, co prowadzi do tworzenia wadliwych żądań CONNECT w HTTP/3 z autorytetem kontrolowanym przez atakującego.

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.0.Final do 4.2.17.Final zawiera podatność na niekontrolowane zużycie zasobów w dekoderze instrukcji strumienia QPACK, pozwalając atakującemu na zadeklarowanie ogromnej długości literału, co prowadzi do nieograniczonego wzrostu bufora i wyczerpania pamięci (OOM).

Dekoder prefiksowanych liczb całkowitych QPACK w Netty (netty-codec-http3) od 4.2.0.Final do 4.2.17.Final nie ogranicza liczby bajtów kontynuacji, co pozwala atakującemu na wywołanie wysokiego zużycia CPU (O(N^2)) i wzrostu pamięci, prowadząc do OOM i zagłodzenia event-loop.

Kodek HTTP/3 w Netty (netty-codec-http3) od 4.2.0.Final do 4.2.17.Final przetrzymuje nieograniczony stan enkodera QPACK dla każdego strumienia, co przy braku potwierdzeń sekcji pozwala na nieograniczony wzrost pamięci i wyczerpanie zasobów (DoS).

Kodek HTTP/3 Netty (io.netty:netty-codec-http3) w wersjach od 4.2.0.Final do 4.2.17.Final nie egzekwuje wymogu RFC 9114, aby pole pseudo-nagłówka :authority i pole nagłówka host, gdy oba są obecne, miały tę samą wartość. Zdalny nieuwierzytelniony peer może wysłać pojedynczą ramkę HEADERS zawierającą oba pola z różnymi, kontrolowanymi przez atakującego wartościami; żądanie jest akceptowane i dostarczane do aplikacji z dwoma sprzecznymi autorytetami, co pozwala obejść decyzje dotyczące routingu, wirtualnych hostów i kontroli dostępu, gdy różne komponenty w ścieżce żądania konsultują różne pola. Problem naprawiono w 4.2.18.Final.

Wada w komponencie `netty-codec-http` biblioteki Netty. Zdalny atakujący może wysłać specjalnie spreparowany token rozmiaru fragmentu HTTP/1.1 zawierający białe znaki po cyfrach. Nieprawidłowe parsowanie rozmiaru fragmentu może prowadzić do przemytu żądań HTTP.

Wada w dekoderze HTTP/1 biblioteki Netty. Niepełna walidacja zniekształconych nagłówków Transfer-Encoding pozwala zdalnemu atakującemu na przemyt żądań HTTP. Poprzez wysyłanie specjalnie spreparowanych żądań HTTP atakujący może wstrzykiwać dowolne żądania HTTP.

W stosie HTTP/2 biblioteki Netty wykryto lukę, która pozwala zdalnemu atakującemu na wstrzyknięcie zabronionych znaków, takich jak NUL, Line Feed i Carriage Return, do wartości pól nagłówka HTTP/2 z powodu niewystarczającej walidacji. Gdy wartości te przekraczają granicę tłumaczenia HTTP/2 na HTTP/1.1, mogą być wykorzystane do przemytu żądań, wstrzykiwania nagłówków lub rozdzielania odpowiedzi.

Luka w Netty netty-codec-smtp polega na nieprawidłowej walidacji znaków CR i LF w polu nazwy komendy SMTP. Zdalny atakujący, jeśli aplikacja przekazuje niezaufane dane do tego pola, może wstrzyknąć dowolne komendy SMTP, prowadząc do przemytu komend SMTP.

W dekoderze HTTP/1.1 biblioteki Netty występuje luka pozwalająca zdalnemu atakującemu obejść walidację nagłówka Transfer-Encoding poprzez podzielenie go na wiele nagłówków, gdzie ostatni zawiera niekońcowe kodowanie transferu, takie jak gzip lub deflate. Obejście to może prowadzić do przemytu żądań HTTP.

Luka w Netty dotyczy procesu konwersji HTTP/1 na HTTP/2. Gdy żądanie HTTP/1 zawiera zarówno absolutny request-target, jak i sprzeczny nagłówek Host, Netty błędnie priorytetowo traktuje nagłówek Host dla pola :authority w HTTP/2, odrzucając oryginalny autorytet request-target.

Luka w Netty polega na nieprawidłowym przetwarzaniu spreparowanych żądań Extended CONNECT HTTP/2 lub HTTP/3 jako zwykłych żądań CONNECT HTTP/1.1. Prowadzi to do utraty krytycznych informacji o protokole i ścieżce.

Wada w kodeku HTTP/2 biblioteki Netty. Przy konwersji żądań HTTP/1 CONNECT na HTTP/2 komponent błędnie używa nagłówka Host zamiast authority-form request-target dla autorytetu tunelu. Zdalny atakujący może dostarczyć inny nagłówek Host, tworząc zniekształcone żądanie HTTP/2 CONNECT.

W bibliotece Netty występuje luka pozwalająca zdalnemu atakującemu wysłać specjalnie spreparowane żądanie HTTP zawierające znaki kontrolne w wierszu rozmiaru fragmentu. Obejście to omija zamierzoną ścisłą walidację, umożliwiając wstrzyknięcie dowolnych żądań HTTP i przemyt żądań.

Wada w komponencie RtspDecoder biblioteki Netty. Funkcja `RtspMethods.valueOf()` nieprawidłowo usuwa końcowe bajty kontrolne z tokenów metod w żądaniach RTSP. Zdalny atakujący może wysłać specjalnie spreparowane żądanie RTSP, prowadząc do przemytu tokenów metod.

Wada w bibliotece Netty. Wyciek licznika referencji w dekoderze komunikatów HAProxy PROXY-v2 pozwala zdalnemu, nieuwierzytelnionemu atakującemu wysyłać specjalnie spreparowane nagłówki PROXY-protocol v2. Prowadzi to do wyczerpania pamięci.

Wada w komponencie WebSocketServerExtensionHandler biblioteki Netty. Zdalny, nieuwierzytelniony atakujący może wykorzystać potokowanie HTTP/1.1 do wysyłania żądań szybciej niż aplikacja jest w stanie odpowiadać. Prowadzi to do nieograniczonego wzrostu kolejki na połączenie i nadmiernego zużycia pamięci.

Wada w kodeku STOMP biblioteki Netty. Zdalny atakujący może wysłać specjalnie spreparowaną ramkę STOMP z nagłówkiem content-length przekraczającym maksymalną wartość całkowitą. Ta podatność na obcięcie liczby całkowitej może prowadzić do nieskończonej pętli dekodowania.

Podatność w Netty zawarta w implementacji HTTP/2 HpackEncoder umożliwia zdalnemu atakującemu wywołanie DoS przez wysłanie ramek SETTINGS z bardzo dużą wartością MAX_HEADER_TABLE_SIZE. Powoduje to nadmierne przechowywanie nagłówków, zwiększając zużycie CPU i pamięci.

W HttpServerCodec biblioteki Netty występuje błąd, który pozwala zdalnemu, nieuwierzytelnionemu atakującemu na potokowanie żądań HTTP/1.1 i wstrzymywanie odczytu, co powoduje nieograniczony wzrost kolejki methodOverflowQueue i wyczerpanie pamięci sterty, prowadząc do odmowy usługi.

W bibliotece Netty, SpdySessionHandler akceptuje nieograniczoną liczbę równoczesnych strumieni inicjowanych zdalnie, ponieważ localConcurrentStreams domyślnie wynosi Integer.MAX_VALUE, a handler nie udostępnia API do zmiany tej wartości. Zdalny peer może otworzyć połączenie SPDY i wysłać wiele ramek SYN_STREAM z FLAG_FIN=0, powodując nieograniczoną alokację pamięci sterty i bezpośredniej, co może prowadzić do OutOfMemoryError w JVM i odmowy usługi.

Podatność w kliencie OCSP Netty polega na braku weryfikacji rozszerzonego użycia klucza (EKU) 'id-kp-OCSPSigning' w certyfikatach odpowiedzi OCSP. Zdalny atakujący posiadający ważny certyfikat od tego samego CA może sfałszować odpowiedzi OCSP typu GOOD dla unieważnionych certyfikatów, co prowadzi do obejścia kontroli odwołań.

Wada w komponencie MqttDecoder biblioteki Netty. Nieuwierzytelniony zdalny atakujący może wysłać specjalnie spreparowany pakiet MQTT CONNECT. Dekoder nie weryfikuje prawidłowo 'Properties Length' względem 'Remaining Length', co pozwala obejść limity rozmiaru.

Wada w komponencie `RedisArrayAggregator` biblioteki Netty. Zdalny atakujący może wysłać specjalnie spreparowane zagnieżdżone nagłówki tablic Redis (RESP). Powoduje to zachłanne wstępne przydzielanie dużej ilości pamięci sterty przez `RedisArrayAggregator`.

Wada w komponencie `SmtpResponseDecoder` biblioteki Netty. Zdalny atakujący, działający jako złośliwy serwer SMTP lub w ataku man-in-the-middle (MITM), może wysłać specjalnie spreparowaną, nieograniczoną wieloliniową odpowiedź SMTP bez terminatora. Prowadzi to do nieograniczonego gromadzenia danych w stercie JVM klienta.

Wada w komponencie StompSubframeDecoder biblioteki Netty pozwala zdalnemu atakującemu wysłać specjalnie spreparowaną ramkę STOMP bez kończącego bajtu null. Powoduje to alokację ByteBuf, który nigdy nie jest zwalniany, prowadząc do trwałego wycieku pamięci. Z czasem niekontrolowane zużycie pamięci może doprowadzić do odmowy usługi (DoS) dla aplikacji korzystającej z dotkniętego kodeka STOMP.

Wada w komponencie netty-handler-ssl-ocsp biblioteki Netty. Zdalny atakujący może dostarczyć odpowiedź OCSP bez opcjonalnego pola nextUpdate, co powoduje ciche pominięcie walidacji OCSP i kontynuowanie pracy z niezweryfikowanym certyfikatem.

Netty w wersjach 4.1.133.Final do 4.1.137.Final oraz 4.2.13.Final do 4.2.17.Final nieprawidłowo waliduje końcowe kodowanie w nagłówku Transfer-Encoding. Atakujący może przemycać żądania, dzieląc nagłówek na wiele linii lub używając wartości takich jak 'chunked, xchunked', co prowadzi do błędnej interpretacji wiadomości.

Netty przed wersjami 4.1.137.Final i 4.2.17.Final zawiera podatność w MqttEncoder, która nie waliduje identyfikatorów klienta, tematów will, nazw użytkowników oraz nazw tematów PUBLISH przed kodowaniem. Może to pozwolić na wstrzyknięcie niedozwolonych bajtów null w polach UTF-8 MQTT, co może prowadzić do błędów routingu, kontroli dostępu lub tożsamości w brokerach.

Netty (io.netty:netty-codec-socks) w wersjach od 4.2.0.Final do 4.2.16.Final oraz od 4.1.x do 4.1.136.Final zawiera podatności na wstrzykiwanie bajtów null, CRLF i poświadczeń w enkoderach klienta SOCKS4 (Socks4ClientEncoder) i SOCKS5 (Socks5ClientEncoder), które nie walidują pól adresu domeny i uwierzytelniania (nazwa użytkownika/hasło). Atakujący kontrolujący te pola może wstrzyknąć bajty null lub znaki CRLF, aby skrócić lub zmienić wartości, co może prowadzić do fałszowania domen, skrócenia userid SOCKS4, wstrzyknięcia danych uwierzytelniających i zamieszania protokołu. Naprawiono w 4.2.17.Final i 4.1.137.Final.

Netty (io.netty:netty-handler) w wersjach od 4.2.0.Final do 4.2.16.Final oraz w wersjach do 4.1.136.Final wyłącza weryfikację nazwy hosta TLS na ścieżce klienta SslProvider.OPENSSL, gdy używany jest zwykły (nie rozszerzony) X509TrustManager i niedostępne jest opakowanie menedżera zaufania oparte na Unsafe (Java 25+). W tej konfiguracji klient OpenSSL nie przeprowadza weryfikacji nazwy hosta, co pozwala atakującemu typu man-in-the-middle na przedstawienie certyfikatu wydanego dla innej nazwy hosta, który jest akceptowany bez weryfikacji. Poprawiono w wersjach 4.2.17.Final i 4.1.137.Final.

W Netty przed wersjami 4.1.137.Final i 4.2.17.Final domyślne konstruktory SniHandler używają ścieżki agregacji ClientHello przed uzgadnianiem, gdzie handshakeBuffer.clear() i writeBytes() kopiują wszystkie wcześniej odebrane bajty dla każdego dodatkowego rekordu TLS. Nieuwierzytelniony zdalny peer może wysłać duży ClientHello w tysiącach małych rekordów, powodując kwadratowy wzrost obciążenia CPU w pętli zdarzeń przed zakończeniem uzgadniania TLS, co pogarsza obsługę TLS dla innych klientów.

Netty przed wersjami 4.1.137.Final i 4.2.17.Final ma podatność w CorsHandler setVaryHeader, która zastępuje nagłówki Vary aplikacji, takie jak Authorization lub Cookie, nagłówkiem Origin, co pozwala buforującemu proxy lub CDN na ponowne użycie uwierzytelnionych odpowiedzi między użytkownikami i ujawnienie wrażliwych informacji.

Netty przed wersjami 4.1.137.Final i 4.2.17.Final ma ograniczenia liczby niekompletnych wiadomości i fragmentów SCTP, ale nie limituje maxBufferedBytes, co pozwala nieuwierzytelnionym peerom na wyczerpanie pamięci dużymi fragmentami SCTP. Problem został naprawiony w wersjach 4.1.137.Final i 4.2.17.Final.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final nie zwalniał obiektów ByteBuf w kodzie DNS, gdy nieprawidłowa nazwa domeny została odrzucona przez IDN.toASCII() lub encodeDomainName(). Zdalne pakiety DNS mogą stopniowo wyciekać pamięć bezpośrednią, prowadząc do odmowy usługi.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final zawiera podatność w XmlFrameDecoder.decode(), która nie zachowuje stanu parsera dla znaczników zamykających między wywołaniami. Zdalny, nieuwierzytelniony atakujący może wysyłać powtarzające się sekwencje </, powodując wielokrotne skanowanie bufora i wyczerpanie CPU wątku EventLoop, co prowadzi do odmowy usługi przy maxFrameLength 1 MB.

W Netty przed wersjami 4.1.136.Final i 4.2.16.Final, kodek RedisArrayAggregator nie czyści stanu częściowego agregatu po przekroczeniu limitu maxElements, co pozwala nieuwierzytelnionemu peerowi na utrzymanie stanu agregatu po wyjątku i przypięcie buforów.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final jest podatny na atak polegający na wymuszeniu aktualizacji WebSocket za pomocą luźnego handshakera V07/V08. Atakujący może wysłać nagłówek Sec-WebSocket-Version: 7, pomijając nagłówki Connection: Upgrade i Upgrade: websocket, co umożliwia przełączenie protokołu nierozpoznawane przez proxy i prowadzi do ataków typu HTTP request smuggling lub protocol confusion.