Podatności Netty

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

W bibliotece Netty (komponent netty-codec-redis) przed wersjami 4.1.135.Final i 4.2.15.Final wykryto podatność na atak DoS. Atakujący może wysłać spreparowany ładunek Redis z głęboko zagnieżdżonymi tablicami, co powoduje alokację ogromnej liczby obiektów stanu i kolekcji, prowadząc do wyczerpania pamięci i błędu OutOfMemoryError.

W Netty przed wersjami 4.1.135.Final i 4.2.15.Final, reguły podsieci IPv6 mogą być omijane z powodu błędnej operacji maskowania w IpSubnetFilterRule.compareTo(). Publiczne adresy IP mogą ominąć ograniczenia.

W bibliotece netty incubator codec.bhttp przed wersją 0.0.21.Final funkcja HKDF_expand zwraca niepustą wartość nawet w przypadku błędu, co prowadzi do użycia zerowego klucza AES. Ponadto EVP_HPKE_CTX_export w przypadku błędu zwraca pustą tablicę zer, co skutkuje deterministycznym, przewidywalnym kluczem AEAD.

Netty to asynchroniczny, sterowany zdarzeniami framework sieciowy. Przed wersjami 4.2.13.Final i 4.1.133.Final, sekcja Properties nagłówka MQTT 5 jest parsowana i buforowana przed zastosowaniem jakiegokolwiek limitu rozmiaru wiadomości. W MqttDecoder metoda decodeVariableHeader() jest wywoływana przed sprawdzeniem bytesRemainingBeforeVariableHeader > maxBytesInMessage. decodeVariableHeader() może wywołać inne metody, które wywołują decodeProperties(). Netty nie stosuje żadnych limitów na rozmiar dekodowanych właściwości. Ponadto, ponieważ MqttDecoder rozszerza ReplayingDecoder, Netty wielokrotnie ponownie parsuje ogromne sekcje Properties i buforuje bajty w pamięci, aż do zakończenia parsowania. Może to powodować wysokie zużycie zasobów zarówno CPU, jak i pamięci. Podatność jest naprawiona w wersjach 4.2.13.Final i 4.1.133.Final.

Podatność w Netty (przed 4.2.13.Final i 4.1.133.Final) w HttpContentDecompressor. Parametr maxAllocation ograniczający rozmiar bufora dekompresji jest poprawnie egzekwowany dla kodowania gzip i deflate, ale jest ignorowany dla br (Brotli), zstd i snappy. Atakujący może ominąć ograniczenie dekompresji, wysyłając skompresowany ładunek z Content-Encoding: br zamiast gzip, co prowadzi do nieograniczonej alokacji pamięci i odmowy usługi (DoS) z powodu braku pamięci. Ta sama podatność istnieje w DelegatingDecompressorFrameListener dla połączeń HTTP/2.

W bibliotece Netty wykryto podatność w komponencie HttpClientCodec, która powoduje nieprawidłowe parowanie odpowiedzi HTTP z żądaniami w przypadku użycia potokowania (pipelining) z żądaniami GET i HEAD. Gdy serwer zwraca odpowiedzi 103 i 200, kolejka paruje odpowiedź HEAD z pierwszą odpowiedzią 200, co prowadzi do błędnego odczytu danych i przesunięcia strumienia.

W bibliotece Netty przed wersją 4.2.13.Final w dekoderze QpackDecoder podczas przetwarzania nagłówków HTTP/3 występuje podatność polegająca na braku weryfikacji długości literału przed alokacją pamięci. Atakujący może przesłać spreparowane ramki, które powodują alokację ogromnych buforów, co prowadzi do wyczerpania pamięci (Denial of Service).

Podatność w Netty przed wersjami 4.2.13.Final i 4.1.133.Final w HttpObjectDecoder umożliwia przemycanie żądań (request smuggling) w przypadku żądań HTTP/1.0 zawierających zarówno Transfer-Encoding: chunked, jak i Content-Length. Atakujący może wysłać takie żądanie, powodując niezgodność interpretacji granic wiadomości.

Netty, asynchroniczny framework sieciowy, zawiera podatność w kodzie DNS, która nie egzekwuje ograniczeń nazw domenowych zgodnych z RFC 1035. Problem występuje zarówno podczas kodowania, jak i dekodowania, co umożliwia atak dwukierunkowy: złośliwe odpowiedzi DNS mogą wykorzystać dekoder, a nazwy hostów kontrolowane przez użytkownika mogą wykorzystać enkoder.

Netty HttpProxyHandler tworzy żądania HTTP CONNECT z wyłączoną walidacją nagłówków, co pozwala na wstrzyknięcie dowolnych nagłówków HTTP przez atakującego kontrolującego nagłówki wyjściowe. Podatność występuje w wersjach przed 4.2.13.Final i 4.1.133.Final.

Podatność w Netty przed wersjami 4.1.132.Final i 4.2.10.Final umożliwia atak DoS przez wysłanie potoku ramek CONTINUATION. Brak limitu liczby ramek oraz obejście ograniczeń rozmiaru za pomocą ramek zerowych powoduje nadmierne zużycie CPU.

Podatność w Netty przed wersjami 4.1.132.Final i 4.2.10.Final powoduje nieprawidłowe parsowanie cytowanych ciągów w wartościach rozszerzeń kodowania transferu fragmentarycznego HTTP/1.1, co umożliwia ataki typu request smuggling.

Podatność w `SniHandler` w frameworku Netty pozwala na alokację do 16MB pamięci heap dla każdego kanału podczas handshake TLS. Brak odpowiednich kontroli pozwala na stworzenie pakietu, który może wykorzystać tę alokację, co prowadzi do potencjalnego wyczerpania zasobów.