Podatności AsyncHttpClient

Podatność w bibliotece AsyncHttpClient (AHC) przed wersjami 3.0.13 i 2.16.1 umożliwia powtórne wysłanie żądania do innego hosta, ale pozostawia oryginalny cel i kontekst proxy. Może to spowodować wysłanie ścieżki, nagłówka Host, poświadczeń lub zwykłego tekstu do miejsca docelowego replikacji.

Biblioteka AsyncHttpClient w wersjach od 2.0.0 do 2.16.1 oraz 3.0.12 przechowuje stan wznawianych pobrań w przewidywalnej współdzielonej ścieżce $java.io.tmpdir/ahc/ResumableAsyncHandler.properties z domyślnymi uprawnieniami i operacjami podążającymi za linkami. Lokalny użytkownik może odczytać adresy URL pobrań lub, jeśli może pisać w tym katalogu, podłożyć dowiązanie symboliczne prowadzące do nadpisania pliku. Podatność dotyczy przypadku, gdy ResumableAsyncHandler dekoruje inny AsyncHandler; konstruktory bezargumentowe używają procesora no-op i nie są podatne. Naprawiono w wersjach 2.16.1 i 3.0.12.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.1.0 do 3.0.14 nie zachowuje informacji o tym, czy odpowiedź Set-Cookie została odebrana przez bezpieczne połączenie. Domyślny ThreadSafeCookieStore akceptuje ciasteczka Secure przesyłane plaintextem i pozwala niezabezpieczonym ciasteczkom nadpisywać lub usuwać istniejące ciasteczka Secure. Atakujący kontrolujący odpowiedź same-site w plaintext może sadzić, zastępować lub usuwać stan ciasteczek wysyłany później do origin HTTPS.

W bibliotece AsyncHttpClient (AHC) przed wersjami 3.0.12 i 2.16.1, żądanie WebSocket przez proxy (ws) jest przekazywane przez CONNECT, ale NettyRequestFactory.newNettyRequest i requestUri decydują o dodaniu uwierzytelnienia proxy i formy absolutnej tylko na podstawie tego, czy URI jest bezpieczny. Ponieważ ws nie jest oznaczony jako bezpieczny, tunelowane uaktualnienie WebSocket wysyłane do origin zawiera wartość Proxy-Authorization proxy. Poświadczenia Basic są bezpośrednio odzyskiwalne, a odpowiedzi Digest mogą być odtwarzane lub łamane offline. Problem naprawiono w wersjach 3.0.12 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) przed wersjami 3.0.12 i 2.16.1 ma podatność w WebSocketHandler.upgrade, która przerywa uzgadnianie (handshake) przy braku lub nieprawidłowej wartości Sec-WebSocket-Accept, ale kontynuuje instalację pipeline'u i dostarczenie onOpen. Ramki połączone z nieprawidłową odpowiedzią 101 mogą być zdekodowane i dostarczone od peera, który nie udowodnił uzgadniania, mimo że przyszłość żądania kończy się niepowodzeniem i kanał jest zamykany. Problem naprawiono w wersjach 3.0.12 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) przed wersjami 3.0.12 i 2.16.1 generuje losowy identyfikator cnonce dla uwierzytelniania Digest przy użyciu ThreadLocalRandom zamiast kryptograficznie bezpiecznego źródła losowości. To sprawia, że mechanizm uwierzytelniania jest podatny na ataki typu wybór tekstu jawnego i prekomputację poświadczeń.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. Przed wersjami 3.0.13 i 2.16.1 klucz puli połączeń HTTP/1.1 nie uwzględnia uwierzytelnionego podmiotu dla uwierzytelniania NTLM i Negotiate zorientowanego na połączenie. Połączony gniazdo uwierzytelnione dla jednego żądania może być ponownie użyte przez żądanie z innym podmiotem, a serwer wykonuje to późniejsze żądanie jako pierwszą tożsamość. Basic i Digest nie są dotknięte, ponieważ uwierzytelniają każde żądanie. Problem naprawiono w wersjach 3.0.13 i 2.16.1.

W bibliotece AsyncHttpClient (AHC) przed wersjami 3.0.13 i 2.16.1, ThreadSafeCookieStore waliduje atrybuty Domain za pomocą dopasowania domen, ale nie odrzuca publicznych sufiksów. Host pod sufiksem takim jak co.uk może ustawić cookie dla tego sufiksu, po czym współdzielony magazyn cookie wysyła je do niepowiązanych hostów pod tym sufiksem. Może to wstrzykiwać lub nadpisywać wartości cookie istotne dla sesji między originami. Problem naprawiono w wersjach 3.0.13 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. W wersji 3.0.12, peer oferujący tylko Digest qop=auth-int powoduje pominięcie weryfikacji wzajemnego uwierzytelniania. AuthenticatorUtils.computeExpectedRspAuth nie zwraca oczekiwanej wartości dla auth-int, a Interceptors traktuje ten wynik jako niezweryfikowany, ale niekrytyczny, więc odpowiedź z nieprawidłową wartością rspauth jest akceptowana. Peer, który nie zna wspólnego sekretu, może zostać zaakceptowany jako uwierzytelniony serwer. Problem naprawiono w wersji 3.0.13.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. Przed wersjami 3.0.12 (na 3.x) i 2.16.1 (na 2.x), klient wnioskuje, że tunel proxy HTTP istnieje na podstawie ostatniej metody żądania, a nie wyniku CONNECT. Po odrzuceniu CONNECT przez proxy, handlery przekierowań lub uwierzytelniania mogą zapisać żądanie pochodzenia i jego poświadczenia Authorization na nadal jawnym połączeniu proxy. Podstawowe poświadczenia mogą być odzyskane bezpośrednio, a odpowiedzi NTLM mogą być złamane lub przekazane dalej. Problem naprawiono w wersjach 3.0.12 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi. Przed wersjami 3.0.13 i 2.16.1, Realm.Builder traktuje wyzwanie Digest, które nie daje użytecznego nonce, jako wyzwanie Basic. Złośliwe źródło lub proxy może oznaczyć wyzwanie jako Digest, pomijając lub opróżniając nonce, co powoduje, że klient wysyła nazwę użytkownika i hasło przy użyciu odwracalnego uwierzytelniania Basic. Dotyczy to zarówno parserów wyzwań źródła, jak i proxy. Problem naprawiono w wersjach 3.0.13 i 2.16.1.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.0.0 do 3.0.14 nieprawidłowo dzieli pulę połączeń dla uwierzytelniania Kerberos, SPNEGO, NTLM oraz połączeń przez autoryzowany proxy. Brakujące pola identyfikujące tożsamość mogą pozwolić na ponowne użycie gniazda uwierzytelnionego jako inna tożsamość, co prowadzi do wykonania żądania w kontekście pierwszej tożsamości i ujawnienia jej danych lub uprawnień innemu wywołującemu. Problem został naprawiony w wersji 3.0.14.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.16.0 do 3.0.14 zawiera niepełną walidację atrybutów Domain w ThreadSafeCookieStore. Brakujące reguły sekcji prywatnej i domyślnych sufiksów publicznych, brak normalizacji A-label, wrażliwe na ustawienia regionalne małe litery, obsługa host-only dla sufiksów publicznych oraz brak kontroli hostów numerycznych lub IP pozwalają jednemu pochodzeniu na zapisanie ciasteczka, które później jest wysyłane do innego pochodzenia. Aplikacje współdzielące jednego klienta między domenami zaufania mogą otrzymać ciasteczka wstrzyknięte przez atakującego i być narażone na fiksację sesji. Problem naprawiono w wersji 3.0.14.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.1.0 do 3.0.14 ma domyślnie włączony magazyn ciasteczek, który zastępuje nagłówek Cookie jawnie dostarczony przez setHeader lub addHeader, gdy magazyn dostarcza jakiekolwiek ciasteczko dla danego pochodzenia. We współdzielonym kliencie zapisane ciasteczka pochodzące od jednego użytkownika mogą zastąpić ciasteczko żądania innego użytkownika, powodując wykonanie żądania w niewłaściwej sesji. To obejście wcześniejszej poprawki CVE-2024-53990, która dotyczyła ciasteczek dostarczanych przez addCookie, ale nie bezpośrednio dostarczanego nagłówka. Problem naprawiono w wersji 3.0.14.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.2.0 do 3.0.14 ma nieograniczoną dekompresję permessage-deflate w WebSocket, gdy kompresja jest włączona. Potok przychodzący agreguje skompresowane ramki przed ich inflacją przez WebSocketClientCompressionHandler, więc webSocketMaxFrameSize i webSocketMaxBufferSize nie ograniczają zdekompresowanego wyjścia. Złośliwy peer WebSocket może wysłać małą skompresowaną wiadomość, która rozszerza się do bardzo dużego bufora Netty i wyczerpuje stertę JVM. Problem został naprawiony w wersji 3.0.14.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.0.0 do 2.16.1 oraz 3.0.12 umożliwia wyciek poświadczeń origin podczas korzystania z proxy HTTP do połączeń HTTPS. NettyRequestFactory i NettyRequestSender.sendRequestWithNewChannel dołączają nagłówek Authorization do zwykłego żądania CONNECT przed ustanowieniem tunelu TLS, przez co poświadczenia Basic, Digest oraz tokeny NTLM, Kerberos lub SPNEGO są widoczne dla proxy i obserwatorów na trasie klient-proxy.

Biblioteka AsyncHttpClient (AHC) w wersjach od 3.0.8 do 3.0.12 nie wymusza weryfikacji wyników uwierzytelniania SCRAM ServerSignature oraz Digest rspauth. W przypadku niezabezpieczonego lub skompromitowanego transportu atakujący może zostać zaakceptowany jako serwer bez znajomości wspólnego sekretu. Luka została naprawiona w wersji 3.0.12.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.0.0 do 2.16.1 oraz 3.0.12 instaluje dekompresor odpowiedzi HTTP/1.1 bez limitu całkowitego rozmiaru zdekompresowanych danych. Złośliwy lub przejęty serwer może wysłać małą odpowiedź gzip, deflate lub snappy, która po dekompresji rozrasta się do ogromnych rozmiarów i wyczerpuje stertę klienta, powodując OutOfMemoryError. Problem dotyczy również brotli i zstd, a w wersjach 3.0.8–3.0.10 także dekompresora HTTP/2.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.1.0 do 2.16.1 oraz 3.0.12 może ujawnić poświadczenia uwierzytelnionego proxy SOCKS serwerowi docelowemu. Nagłówek Proxy-Authorization jest dołączany bez potwierdzenia, że żądanie jest wysyłane do proxy HTTP, co przy preemptive authentication ujawnia dane logowania w jawnym tekście, a przy domyślnym przepływie złośliwy origin może wymusić przesłanie poświadczeń NTLM, Kerberos lub SPNEGO przez tunel SOCKS.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi HTTP. Od wersji 3.0.8 do 3.0.12, klient z ustawionym maxConnections lub maxConnectionsPerHost powyżej zera wycieka jeden permit połączenia, gdy ustanowienie połączenia TLS nie powiedzie się przed zakończeniem uzgadniania. NettyConnectListener usuwa permit partitionKeyLock z NettyResponseFuture przed każdą ścieżką błędu, która jest powiązana z closeFuture kanału, więc przerwanie może pozostawić permit niezwolniony. Powtarzające się błędy mogą trwale zablokować jeden host przy limicie per-host lub wyczerpać wspólną pulę przy limicie globalnym, blokując późniejsze żądania nawet gdy żadne połączenie nie pozostaje otwarte. Domyślne ustawienie nieograniczonej liczby połączeń nie jest dotknięte. Problem został naprawiony w wersji 3.0.12.

Biblioteka AsyncHttpClient (AHC) umożliwia aplikacjom Java łatwe wykonywanie żądań HTTP i asynchroniczne przetwarzanie odpowiedzi HTTP. Od wersji 2.14.5 do 2.16.0 oraz od 3.0.9 do 3.0.11, klient skonfigurowany z globalnym Realm i podążaniem za przekierowaniami może ujawnić poświadczenia po przekierowaniu między domenami, ponieważ ścieżka uwierzytelniania Interceptors wraca do konfiguracji klienta po tym, jak obsługa przekierowań wyczyści realm dla bieżącej wymiany. Jeśli cel kontrolowany przez atakującego zwróci 401, klient może wysłać poświadczenia Basic lub Digest lub token Negotiate lub NTLM do tego źródła. Realm dla poszczególnych żądań są usuwane poprawnie, a ten problem jest resztkowym obejściem wcześniejszych poprawek usuwających poświadczenia między domenami. Problem został naprawiony w wersjach 2.16.1 i 3.0.12.

Biblioteka AsyncHttpClient (AHC) w wersjach od 2.0.0 do 2.15.0 oraz od 3.0.0.Beta1 do 3.0.10 zawiera podatność w ThreadSafeCookieStore, która nie weryfikuje, czy host odpowiadający ma prawo ustawić ciasteczko dla domeny. Umożliwia to atakującemu hostowi wstrzyknięcie ciasteczka dla niepowiązanej domeny, które klient następnie wysyła do tej domeny.

Biblioteka AsyncHttpClient (AHC) w wersjach 2.x przed 2.15.0 i 3.x przed 3.0.10 wycieka nagłówki Cookie do docelowych przekierowań między domenami. Podczas przekierowania do innego pochodzenia nagłówek Cookie nie jest usuwany, co umożliwia wysłanie ciasteczek sesyjnych do serwerów atakującego. Podatność naprawiona w wersjach 2.15.0 i 3.0.10.