Podatności Netty

Netty przed wersjami 4.2.13.Final i 4.1.133.Final ma podatność w Lz4FrameDecoder, który alokuje ByteBuf o rozmiarze decompressedLength, co może prowadzić do niekontrolowanego przydziału pamięci. Atakujący może wykorzystać 21-bajtowy nagłówek oraz skompresowane dane, aby wymusić tę alokację.

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

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.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final nie sprawdza ani nie koduje wartości nagłówków w ramkach CONNECT i CONNECTED w STOMP, co pozwala atakującemu na wstrzyknięcie dodatkowych nagłówków STOMP poprzez kontrolowanie wartości nagłówka (np. login lub hasło). Może to prowadzić do ominięcia uwierzytelniania lub eskalacji uprawnień w zależności od brokera.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final nie sprawdza adresów AF_UNIX pod kątem znaków CRLF w enkoderze HAProxyMessageEncoder, co pozwala atakującemu na wstrzyknięcie sekwencji \r\n i podzielenie nagłówka PROXY na wiele linii. Umożliwia to fałszowanie adresu źródłowego/docelowego klienta dla serwera downstream lub load balancera.

W Netty przed wersjami 4.1.136.Final i 4.2.16.Final handler `Bzip2Decoder` w potoku kompresji jest podatny na atak DoS poprzez nieprawidłowy strumień bzip2, który powoduje nieskończoną pętlę w wątku event-loop. Podatność istnieje w maszynie stanów RLE w `Bzip2BlockDecompressor.read()`.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final nie deduplikuje ani nie sprawdza nagłówków Host podczas tłumaczenia HTTP/2 na HTTP/1.x. Gdy klient HTTP/2 dostarczy zarówno pseudo-nagłówek :authority, jak i literalny nagłówek host, tłumacz tworzy obiekt HttpRequest z dwoma różnymi nagłówkami Host, co może prowadzić do ataków typu request smuggling lub cache poisoning.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final ma podatność na wyczerpanie zasobów w HttpContentEncoder (nadklasie HttpContentCompressor). Kolejka acceptEncodingQueue gromadzi dane kontrolowane przez atakującego bez ograniczeń rozmiaru, co przy użyciu pipeliningu HTTP/1.1 może doprowadzić do wyczerpania pamięci lub zasobów I/O.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final ma podatność w `OcspServerCertificateValidator`, która przekazuje zdarzenie `SslHandshakeCompletionEvent` przed zakończeniem asynchronicznej walidacji OCSP. Pozwala to klientowi na wysłanie wrażliwych danych do odwołanego serwera przed zamknięciem kanału.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final ma podatność w `OcspServerCertificateValidator`, która oznacza nieaktualną odpowiedź OCSP jako ważną, nawet jeśli wygasła. Pozwala to atakującemu na powtórne użycie starej odpowiedzi GOOD w celu ominięcia odwołania certyfikatu.

W Netty przed wersjami 4.1.136.Final i 4.2.16.Final, konstruktor HttpPostRequestEncoder tworzy wieloczęściowe żądania HTTP, bezpośrednio łącząc nazwy plików i pól dostarczone przez użytkownika z nagłówkami MIME Content-Disposition, bez walidacji znaków CRLF (\r\n). Atakujący kontrolujący nazwę pliku może wstrzyknąć dowolne nagłówki MIME. Problem rozwiązano w wersjach 4.1.136.Final i 4.2.16.Final.

Netty w wersjach 4.2.0.Final do 4.2.15.Final oraz przed 4.1.135.Final nie waliduje, czy CertificateID w odpowiedzi OCSP odpowiada żądanemu CertificateID. Umożliwia to atak typu replay, pozwalający na obejście sprawdzania odwołania certyfikatu.

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 której zdalny, nieuwierzytelniony peer może wyciekać jeden bezpośredni ByteBuf na ramkę HTTP/2 DATA w aplikacjach włączających dekompresję treści HTTP/2 przez DelegatingDecompressorFrameListener. Gdy ramka DATA jest przetwarzana dla strumienia, którego dekompresor został już zamknięty, Http2Decompressor.decompress(...) wywołuje decompressor.writeInbound(data.retain()) i nie zwalnia zatrzymanego bufora na ścieżce błędu, co prowadzi do wyczerpania pamięci bezpośredniej i awarii JVM.

W Netty przed wersją 4.2.16.Final, Http3FrameCodec buforuje przychodzące dane dla zarezerwowanych typów ramek HTTP/3 bez ograniczeń, ufając polu payLoadLength, co pozwala atakującemu na otwarcie wielu strumieni QUIC i wysłanie ramek z dużymi ładunkami, powodując wyczerpanie pamięci i odmowę usługi.

Netty w wersjach 4.2.0.Final do 4.2.15.Final oraz 4.1.0.Final do 4.1.135.Final jest podatny na obejście kontroli bezpieczeństwa podczas procesu oceny pochodzenia żądania. CorsHandler udostępnia konfigurację shortCircuit() zaprojektowaną do natychmiastowego odrzucania nieautoryzowanych żądań cross-origin, ale z powodu błędu logicznego w procesie oceny pochodzenia, ochrona ta może zostać całkowicie ominięta. Atakujący może ominąć mechanizm short-circuit, wysyłając żądanie z nagłówkiem Origin: null. To powoduje przekazanie nieautoryzowanych żądań do aplikacji backendowej, omijając zamierzone kontrole dostępu. Problem został naprawiony w wersjach 4.1.136.Final i 4.2.16.Final.