Katalog podatności CVE

Centrale telefoniczne Slican używają szyfrowania symetrycznego do komunikacji TCP/IP, a klucz tajny jest zaszyty na stałe w wielu plikach binarnych. Atakujący mający dostęp do tych plików może odszyfrować komunikację.

W Eclipse Jetty w różnych wersjach jetty-annotations i jetty-eeN-annotations reguły autorytatywnego wzorca URL dla mieszanego zastosowania adnotacji @ServletSecurity i ograniczenia security-constraint z web.xml na tym samym wzorcu URL nie były stosowane, gdy web.xml zawierał więcej niż jeden wzorzec URL dla serwletu, a ograniczenie dotyczyło tylko części z nich.

Słaby mechanizm odzyskiwania hasła w produktach Mitsubishi Electric GENESIS, GENESIS64, ICONICS Suite, Hyper Historian, AnalytiX, MobileHMI, IoTWorX, MC Works64, GENESIS32 i BizViz pozwala uwierzytelnionemu lokalnemu użytkownikowi z uprawnieniami administracyjnymi odblokować system poprzez manipulację plikiem zarządzania przechowującym odpowiedź na wyzwanie. Administratorzy mogą odczytywać i zapisywać ten plik, ale jest on chroniony przez Windows.

W bibliotece undici (klient HTTP dla Node.js) w wersjach 8.11.0 i 8.11.1 eksperymentalny klient WebSocket, domyślnie włączony gdy dozwolone jest HTTP/2, błędnie obsługuje nieudany handshake WebSocket przez HTTP/2: żądanie jest już oznaczone jako zakończone, więc przerwanie staje się bezskuteczne, a strumień HTTP/2 pozostaje otwarty bez nasłuchiwacza błędów. Gdy złośliwy serwer zniszczy połączenie, osierocony strumień emituje nieobsłużony błąd i proces Node.js kończy działanie.

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, 5.2.0] dekoder komunikatów MySQL agreguje przychodzące wielopakietowe ładunki do złożonego bufora pamięci bezpośredniej bez limitu łącznego rozmiaru. Złośliwy, przejęty lub pośredniczący serwer MySQL może wysyłać ciągły strumień pakietów o maksymalnej długości ładunku (0xFFFFFF), uniemożliwiając osiągnięcie warunku końca komunikatu i powodując nieograniczoną alokację pamięci bezpośredniej po stronie klienta oraz awarię z powodu braku pamięci.

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, 5.2.0] dekoder komunikatów PostgreSQL odczytuje 4-bajtowe pole długości komunikatu z protokołu PostgreSQL bez walidacji maksymalnej wartości. Złośliwy, przejęty lub pośredniczący serwer PostgreSQL może wysłać nagłówek komunikatu z polem długości ustawionym na ekstremalnie dużą wartość (do Integer.MAX_VALUE), powodując nieograniczone gromadzenie danych TCP w buforze złożonym i nieograniczoną alokację pamięci po stronie klienta oraz awarię z powodu braku pamięci.

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.

Zdalny atakujący może wysłać specjalnie spreparowany pakiet sieciowy, który powoduje odczyt pamięci poza zakresem z powodu niewystarczającej walidacji długości pakietu. Może to doprowadzić do awarii aplikacji.

W Rancher użytkownik mający możliwość tworzenia projektów w danym klastrze może utworzyć projekt o tej samej nazwie co istniejący projekt w innym klastrze. Prowadzi to do uzyskania dostępu do tego drugiego projektu w innym klastrze i eskalacji uprawnień, ponieważ przestrzeń nazw używana w lokalnym klastrze do przechowywania powiązanych zasobów (PRTB i sekretów) to nazwa projektu.

W Steve domyślnie używana była niezabezpieczona opcja, która nie weryfikowała certyfikatu prezentowanego przez zdalny serwer podczas nawiązywania połączenia TLS. Mogło to umożliwić przeprowadzenie ataku man-in-the-middle (MitM) na usługi korzystające ze Steve.

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.

W modelu urządzenia framebuffer w bhyve stałe maksymalnej rozdzielczości były zduplikowane między modułami framebuffer i RFB i rozjechały się. Dodatkowo zapisy do BAR framebuffer mogły ustawiać dowolne wartości szerokości i wysokości bez walidacji, a wątki I/O BAR i renderowania RFB nie były zsynchronizowane.

W modelu urządzenia audio HDA w bhyve nie sprawdzano wpisów Buffer Descriptor List (BDL) o zerowej długości przy starcie strumienia. Wpis o zerowej długości powodował odczyt lub zapis poza granicami podczas przetwarzania transferu DMA. Pola BDL mogły być też modyfikowane przez gościa po walidacji.