Podatności Eclipse Vert.x

W Eclipse Vert.x w wersjach [5.0.0,5.0.12], [5.1.0,5.1.9] oraz [5.2.0, 5.2.0] klient HTTP Vert.x korzysta z pamięci podręcznej kontekstu SSL, której klucz nie odzwierciedla w pełni semantyki właściwości SSL. Klient może otrzymać kontekst SSL o słabszych właściwościach, na przykład kontekst ignorujący walidację nazwy hosta zamiast kontekstu z walidacją. Dotyczy komponentu io.vertx:vertx-core.

W bibliotece Eclipse Vert.x (moduł vertx-grpc-server) limit maksymalnego rozmiaru wiadomości gRPC jest sprawdzany względem rozmiaru skompresowanego, a nie rzeczywistego rozmiaru po dekompresji. Umożliwia to atakującemu przesłanie skompresowanej wiadomości, która po rozpakowaniu zajmuje znacznie więcej pamięci niż skonfigurowany limit.

W kliencie MySQL biblioteki Eclipse Vert.x (vertx-mysql-client) tablica definicji kolumn jest alokowana na podstawie liczby kolumn zadeklarowanej przez serwer, bez walidacji górnego limitu. Złośliwy lub przejęty serwer MySQL (lub atakujący w pozycji man-in-the-middle) może wysłać spreparowany pakiet z ogromną liczbą kolumn, powodując masową alokację sterty.

W kliencie MQTT biblioteki Eclipse Vert.x (vertx-mqtt) klient MqttClient przechowuje każdą przychodzącą wiadomość PUBLISH QoS 2 w wewnętrznej mapie (qos2inbound) do czasu otrzymania pakietu PUBREL. Mapa ta nie ma limitu rozmiaru, a opcja maxInflightQueue ogranicza tylko ruch wychodzący.

W dekoderze tablic binarnych klienta PostgreSQL biblioteki Eclipse Vert.x (vertx-pg-client, DataTypeCodec.binaryDecodeArray) alokowana jest tablica Java o rozmiarze wynikającym z 32-bitowej liczby wymiarów zadeklarowanej przez serwer, bez górnego limitu. Złośliwy lub przejęty serwer PostgreSQL (lub atakujący w ścieżce na nieszyfrowanym połączeniu) może wysłać spreparowaną wiadomość DataRow z ogromną wartością wymiaru tablicy.

W dekoderze wiadomości TDS klienta MSSQL biblioteki Eclipse Vert.x (vertx-mssql-client) przychodzące pakiety TDS są agregowane w bufor pamięci bezpośredniej bez limitu skumulowanego rozmiaru. Złośliwy, przejęty lub działający jako man-in-the-middle serwer SQL może wysyłać ciągły strumień pakietów TDS bez ustawiania flagi END_OF_MESSAGE.

W bibliotece Eclipse Vert.x walidacja słowa kluczowego uniqueItems (moduł vertx-json-schema) wykorzystuje pętlę porównań parami o złożoności O(n²) bez krótkiego spięcia ani limitu rozmiaru. Zdalny, nieuwierzytelniony atakujący może przesłać umiarkowanie dużą tablicę JSON, która zużywa nieproporcjonalnie dużo czasu CPU.

W Eclipse Vert.x (moduł vertx-http-proxy) interceptor transformujący ciało żądania opiera się na limicie maksymalnej liczby buforowanych bajtów, aby zapewnić ograniczony bufor dla każdego żądania. Można to wykorzystać do wymuszenia na serwerze nieograniczonej alokacji sterty. Podatność wymaga użycia interceptora transformującego ciało.

W bibliotece Eclipse Vert.x w wersjach [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] oraz [5.2.0, 5.2.0] implementacja WebSocket nie określa maksymalnej liczby bajtów alokowanych podczas dekompresji ramek lub wiadomości. Umożliwia to przeprowadzenie ataku typu zip bomb prowadzącego do wyczerpania zasobów.

W bibliotece Eclipse Vert.x w wersjach [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] oraz [5.2.0, 5.2.0] parser RESP klienta Redis prealokuje tablice do długości zadeklarowanej przez serwer bez górnego limitu. Złośliwy lub przejęty serwer Redis, albo atakujący w pozycji man-in-the-middle, może wysłać spreparowaną odpowiedź RESP deklarującą ekstremalnie dużą długość tablicy, push lub atrybutu, powodując próbę ogromnej alokacji sterty.

Dekoder HTTP/1.x w Eclipse Vert.x w wersjach [5.0.0,5.0.12], [5.1.0,5.1.9] i [5.2.0,5.2.0] stosuje kanonikalizację znanych nagłówków HTTP, która błędnie interpretuje spreparowane nagłówki jako nagłówki z listy, np. Content-Xength jako Content-Length. Umożliwia to przeprowadzenie ataku request smuggling.

W Eclipse Vert.x w wersjach [4.0.0, 4.5.34], [5.0.0, 5.0.12], [5.1.0, 5.1.9] i 5.2.0 komponent vertx-mail-client nie usuwa znaków CR/LF z nazw i wartości nagłówków e-mail przed zapisaniem ich do sekcji SMTP DATA. Wstrzyknięcie sekwencji CR/LF pozwala dodać dowolne nagłówki (np. Bcc, Reply-To) lub dopisać treść do wiadomości; ta sama słabość dotyczy metadanych części MIME.

W Eclipse Vert.x do wersji 4.5.29 (4.x) i 5.1.4 (5.x) komponent DefaultRedirectHandler (vertx-core) przekazuje wszystkie nagłówki żądania, w tym uwierzytelniające (Authorization, Cookie, Proxy-Authorization) oraz niestandardowe (np. X-API-Token), podczas przekierowań HTTP 30x między różnymi źródłami. Brak weryfikacji pochodzenia (schemat, host, port) przed skopiowaniem nagłówków do celu przekierowania.

W Eclipse Vert.x w wersjach [4.0.0, 4.5.21] oraz [5.0.0, 5.0.4], gdy włączone jest wyświetlanie listy katalogów, nazwy plików i katalogów są wstawiane do generowanego HTML bez odpowiedniego escapowania w atrybutach href, title i link. Atakujący mogący tworzyć lub zmieniać nazwy plików w udostępnianym katalogu może wywołać przechowywany XSS.

W Eclipse Vert.x w wersjach [4.0.0, 4.5.21] i [5.0.0, 5.0.4], konfiguracja StaticHandler mająca ograniczać dostęp do ukrytych plików nie ogranicza dostępu do ukrytych katalogów, co pozwala nieautoryzowanym użytkownikom na pobieranie plików z tych katalogów (np. '.git/config').

W Eclipse Vert.x wykryto podatność powodującą wyciek pamięci w serwerach TCP skonfigurowanych z TLS i obsługą SNI. Podczas przetwarzania nieznanej nazwy serwera SNI, której przypisano domyślny certyfikat zamiast mapowanego, kontekst SSL jest błędnie buforowany w mapie nazw serwerów, co prowadzi do wyczerpania pamięci. Atakujący może wysyłać wiadomości TLS client hello z fałszywymi nazwami serwerów, wywołując błąd braku pamięci w JVM.

Podatność w Eclipse Vert.x powoduje wyciek pamięci z powodu użycia struktur danych Netty FastThreadLocal. Wyciek występuje, gdy klient HTTP Vert.x nawiązuje połączenia z różnymi hostami, a może być przyspieszony przez atakującego z dogłębną znajomością środowiska wykonawczego. Serwer akceptujący dowolne adresy internetowe może służyć jako wektor ataku, przyspieszając wyciek pamięci.