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

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.

W Netty do wersji 4.1.135 i 4.2.15 występuje podatność w handlerze SpdyHttpDecoder. Nieprawidłowe zwalnianie pulowanego bufora ByteBuf prowadzi do wyczerpania pamięci natywnej.

Netty, framework aplikacji sieciowych, zawiera podatność w module codec-haproxy w klasie HAProxyMessageDecoder. Podczas odczytu 13. bajtu jako signed byte i rozszerzania go do int bez maskowania, wartość 0xFF jest interpretowana jako -1, co powoduje kolizję z sentinelą oznaczającą potrzebę więcej danych. Prowadzi to do niekontrolowanego gromadzenia danych w buforze cumulation, aż do wyczerpania pamięci bezpośredniej.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final kontynuuje dekompresję nagłówków SPDY po przekroczeniu maxHeaderSize, co pozwala zdalnemu peerowi na wysłanie małego skompresowanego bloku HEADERS, który rozszerza się do znacznie większych danych, powodując wzmocnienie kompresji i przeciążenie CPU oraz alokacji.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final akceptuje zadeklarowaną przez peera liczbę wpisów SETTINGS do limitu ramki 24-bitowej i materializuje każdy unikalny identyfikator ustawienia w DefaultSpdySettingsFrame, co pozwala zdalnemu peerowi SPDY/3.1 na wysłanie ramki SETTINGS o rozmiarze około 2 MiB, która tworzy 262144 wpisów mapy, wzmacniając ruch sieciowy w wzrost sterty i pracę przy wstawianiu do uporządkowanej mapy.

Netty przed wersjami 4.1.136.Final i 4.2.16.Final zawiera lukę w dekompresji ramek STOMP, gdzie StompSubframeDecoder nie ogranicza całkowitej liczby nagłówków ani ich skumulowanego rozmiaru. Atakujący może wysłać wiele krótkich nagłówków, powodując wyczerpanie pamięci JVM i odmowę usługi.

Netty, framework do aplikacji sieciowych, przed wersjami 4.1.135.Final i 4.2.15.Final miał problem z obsługą maksymalnego rozmiaru nagłówków HTTP/2, co umożliwiało atak podobny do ataku HTTP/2 Rapid Reset. W wyniku tego, podczas przetwarzania żądania mogło dojść do wyjątków przy zapisie nagłówków odpowiedzi.

W wersjach przed 4.1.135.Final i 4.2.15.Final, `HttpObjectDecoder` w frameworku Netty pomijał bajty kontrolne oraz białe znaki przed odczytem pierwszej linii żądania. To może prowadzić do nieprawidłowego rozpoznawania granic żądania w złożonych transportach, co stwarza ryzyko ataków.

Podatność w Netty RedisArrayAggregator pozwala na prealokację ArrayList o rozmiarze zadeklarowanym w nagłówku tablicy RESP, który może być zawyżony przez złośliwy pakiet. Atakujący może wysłać mały nagłówek z fałszywą dużą liczbą elementów, co prowadzi do nadmiernego zużycia pamięci.

Netty przed wersjami 4.1.135.Final i 4.2.15.Final zawiera podatność w SimpleTrustManagerFactory, która powoduje pominięcie weryfikacji nazwy hosta. Klient skonfigurowany z SslContextBuilder.forClient().trustManager() nie sprawdza poprawności certyfikatu względem nazwy hosta, nawet gdy ustawiono endpointIdentificationAlgorithm="HTTPS".

Netty to framework do tworzenia aplikacji sieciowych. W wersjach od 4.2.0.Final do 4.2.15.Final występuje podatność na wyczerpanie pamięci w kodzie HTTP/3, umożliwiająca utworzenie nieskończonej liczby zablokowanych strumieni, co może prowadzić do błędu OOM. Problem został naprawiony w wersji 4.2.15.Final.

Podatność w Netty powoduje wyciek pamięci natywnej lub sterty przy każdym połączeniu, gdy klient wysyła poprawny składniowo nagłówek HAProxy PROXY protocol v2 zawierający zagnieżdżone rekordy TLV typu PP2_TYPE_SSL na głębokości dwóch lub więcej. Wyciek występuje na ścieżce poprawnego parsowania, bez zgłaszania wyjątku, a zwolnienie obiektu HAProxyMessage nie uwalnia skumulowanego bufora.

W Netty przed wersjami 4.1.135.Final i 4.2.15.Final, w klasie DelegatingDecompressorFrameListener, zdalny atakujący może wysłać ramki HTTP/2 powodujące wyciek zasobów, co może doprowadzić do wyczerpania pamięci i awarii JVM.

W bibliotece Netty wykryto podatność polegającą na trwałym wycieku buforów pamięci bezpośredniej (direct memory) w handlerze RedisArrayAggregator. Gdy połączenie Redis zostanie zamknięte przed zakończeniem agregacji odpowiedzi RESP, handler nie zwalnia przechowywanych buforów, co prowadzi do wyczerpania puli pamięci bezpośredniej. Problem został załatany w wersjach 4.1.135.Final i 4.2.15.Final.

Podatność w bibliotece Netty umożliwia zatrucie pamięci podręcznej DNS poprzez niewystarczającą walidację rekordów NS w `DnsResolveContext`. Atakujący kontrolujący autorytatywny serwer DNS dla subdomeny może dodać fałszywe rekordy A dla domen nadrzędnych do pamięci podręcznej, co prowadzi do przekierowania ruchu.

Netty, framework do aplikacji sieciowych, przed wersjami 4.1.135.Final i 4.2.15.Final, nie ogranicza liczby aktywnych strumieni w HTTP/2, co może prowadzić do nadmiernego zużycia zasobów. Brak domyślnego limitu na maksymalną liczbę strumieni może skutkować tworzeniem setek tysięcy obiektów strumieni w pojedynczym połączeniu TCP.

W bibliotece Netty w modułach netty-transport-sctp przed wersjami 4.1.135.Final i 4.2.15.Final występuje podatność na wyczerpanie zasobów. Dla każdego niekompletnego fragmentu SctpMessage handler tworzy nowy obiekt CompositeByteBuf, co prowadzi do rekurencyjnego zagnieżdżania buforów. Atakujący może wysyłać małe fragmenty bez flagi 'complete', powodując nieograniczony wzrost struktury danych i potencjalne wyczerpanie pamięci.

Podatność w bibliotece Netty dotyczy braku walidacji pochodzenia (bailiwick) rekordów CNAME w odpowiedziach DNS. DnsResolveContext nie sprawdza, czy rekord CNAME pochodzi z autorytatywnego źródła, co może prowadzić do ataków typu DNS cache poisoning.

Netty, framework do aplikacji sieciowych, przed wersjami 4.1.135.Final i 4.2.15.Final, używał przewidywalnego PRNG do generowania identyfikatorów transakcji DNS oraz domyślnie statycznego portu źródłowego UDP. To połączenie zmniejsza entropię zapytań DNS, co umożliwia atak typu DNS Cache Poisoning.

W wersjach przed 4.1.135.Final i 4.2.15.Final frameworku Netty występuje podatność związana z nieprawidłowym przetwarzaniem komunikatów SCM_RIGHTS, co prowadzi do wycieku deskryptorów plików. W wyniku błędnej obsługi długości komunikatu, dwa deskryptory plików mogą zostać zainstalowane w procesie odbierającym, ale nie zostaną zamknięte.

W Netty przed wersjami 4.1.135.Final i 4.2.15.Final, w metodzie SslClientHelloHandler.decode() występuje podatność na nadmierną alokację pamięci. Gdy ClientHello nie mieści się w pierwszym rekordzie, handler alokuje bufor o rozmiarze handshakeLength, a domyślne konstruktory SniHandler/AbstractSniHandler wyłączają zabezpieczenia (maxClientHelloLength=0, handshakeTimeoutMillis=0). Żądanie o rozmiarze 16 MiB powoduje natychmiastową alokację dużego, niebuforowanego bloku pamięci, który jest przechowywany aż do zamknięcia kanału.

Podatność w bibliotece Netty dotyczy domyślnego handlera tokenów QUIC (NoQuicTokenHandler), który zawsze uznaje dowolny token za poprawny. Atakujący może wysłać pakiet Initial z dowolnym tokenem i sfałszowanym źródłowym adresem IP ofiary, co powoduje, że serwer traktuje ofiarę jako zweryfikowaną i wysyła do niej pełne odpowiedzi bez ograniczenia amplifikacji 3×.

W bibliotece Netty w komponencie netty-codec-haproxy przed wersjami 4.1.135.Final i 4.2.15.Final występuje podatność na wyciek pamięci. Podczas dekodowania TLV typu PP2_TYPE_SSL, gdy atakujący ustawi długość TLV poniżej 5 bajtów, dochodzi do wyjątku IndexOutOfBoundsException, który nie jest poprawnie obsługiwany, co prowadzi do nienaruszonego wycieku bufora.

Podatność w bibliotece Netty (netty-codec-redis) przed wersjami 4.1.135.Final i 4.2.15.Final umożliwia atak DoS poprzez wysyłanie spreparowanych ładunków Redis bez znaku `\r\n` na wielu połączeniach. Powoduje to wyczerpanie puli pamięci bezpośredniej serwera (OutOfDirectMemoryError), uniemożliwiając przetwarzanie prawidłowych połączeń.