Katalog podatności CVE

W RabbitMQ w wersjach od 3.13.0 do 3.13.18, 4.0.23, 4.1.14, 4.2.9 i 4.3.3 występuje podatność Stored XSS w interfejsie zarządzania strumieniami. Nazwa DN z certyfikatu TLS peera jest renderowana bez escapowania, co pozwala na wstrzyknięcie złośliwego kodu HTML/JavaScript. Wymaga to konfiguracji z listenerem TLS i verifypeer oraz certyfikatu zaufanego przez listener, z atakującym kontrolowanym DN.

W RabbitMQ w wersjach od 4.2.0 do 4.2.8 i 4.3.2 funkcja set_token_auth/2 wstawiała token bearer z nagłówka Authorization lub ciasteczka access_token do JavaScriptu bootstrap OAuth bez escapowania. Pozwalało to na wykonanie kodu JavaScript w kontekście interfejsu zarządzania. Luka jest eksponowana przed uwierzytelnieniem tylko gdy management.oauth_enabled jest true, a ścieżka przez ciasteczko wymaga dodatkowo umieszczenia ciasteczka access_token na hoście zarządzania.

RabbitMQ w wersjach 4.2.0 do 4.2.8 i 4.3.2 zawiera podatność w funkcji get_auth_mechanism/1, która przy czyszczeniu ciasteczka używa term_to_binary/1 na atomie strict_auth_mechanism lub preferred_auth_mechanism. Powoduje to wygenerowanie nie-ASCII nazwy ciasteczka, co narusza RFC 6265 i może uniemożliwić przeglądarce usunięcie ustawień. Podatność nie ma bezpośredniego wpływu na wykonanie kodu, ale wpływa na trwałość preferencji po wylogowaniu.

Handler WebSocket Web STOMP w RabbitMQ nie wymusza max_frame_size ani login_timeout przed uwierzytelnieniem, co pozwala nieuwierzytelnionemu klientowi utrzymać połączenie wolnym strumieniem małych ramek i gromadzić nieograniczony stan przed uwierzytelnieniem. Wymagane jest włączenie wtyczki rabbitmq_web_stomp.

W RabbitMQ w wersjach od 4.0.0 do 4.0.22, 4.1.14, 4.2.7 i 4.3.1 występuje podatność polegająca na wyczerpaniu atomów. Funkcja toatom/1 jest wywoływana na segmencie ścieżki URL :name w endpointach global-parameters, co pozwala użytkownikowi z uprawnieniami policymaker na wielokrotne żądania i wyczerpanie tablicy atomów, prowadząc do awarii węzła.

W RabbitMQ w wersjach od 4.0.0 do 4.0.22, 4.1.14 i 4.2.7 występuje podatność polegająca na wyczerpaniu atomów dostępna tylko dla administratora. Funkcja settags/2 wywołuje toatom/1 na liście tagów użytkownika, a limit rozmiaru ciała żądania (20 MB) pozwala na przesłanie około 3-4 milionów krótkich tagów. Administrator może doprowadzić do awarii węzła pojedynczym żądaniem.

W RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 protokół strumieniowy przechowuje wartość FrameMax wynegocjowaną podczas uzgadniania Tune, ale nie porównuje jej z deklarowaną długością przychodzącej ramki przed buforowaniem. Zdalny klient może spowodować nadmierne zużycie pamięci i odmowę usługi, deklarując zbyt dużą ramkę.

W RabbitMQ w liniach 3.13, 4.0, 4.1, 4.2 i 4.3 funkcja fill/2 podstawia ${username} do user_dn_pattern bez escapowania RFC 4514 DN, co pozwala na modyfikację powiązanego DN LDAP przez spreparowaną nazwę użytkownika. Wykorzystanie wymaga włączonego backendu rabbitmq_auth_backend_ldap z wzorcem zawierającym ${username}, odpowiedniego układu katalogu i ważnego hasła. Wersje poprawione są sprzeczne w różnych źródłach.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 ma podatność polegającą na zastosowaniu list_to_atom/1 do każdego tokena rozdzielanego dwukropkiem w kontrolowanej przez atakującego wartości auth_mechanism, co trwale zużywa atomy maszyny wirtualnej Erlanga i może doprowadzić do awarii węzła przy dużym żądaniu. Eksploatacja wymaga użycia wtyczek Shovel lub Federation oraz posiadania tagu policymaker.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 zawiera podatność polegającą na obejściu ochrony tagu 'protected' poprzez masowe usuwanie użytkowników. Administrator może usunąć konta usługowe oznaczone jako chronione, korzystając z punktu końcowego bulk-delete, co omija zabezpieczenie sprawdzające tag 'protected'.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.20, 4.1.11 i 4.2.6 ma podatność na wyczerpanie tablicy atomów przez pole node w API zarządzania. Żądanie PUT /api/queues/:vhost/:name (oraz endpointy exchanges i bindings) przyjmuje pole JSON node, które jest konwertowane na atom bez sprawdzenia przynależności do klastra. Każda unikalna wartość trwale wycieka jeden atom, a około 900 tysięcy żądań może zawiesić maszynę wirtualną.

RabbitMQ w wersjach od 3.13.0 do 3.13.15, 4.0.22, 4.1.11, 4.2.6 i 4.3.1 ma podatność na wyczerpanie atomów przez wartości scope w tokenach OAuth2 JWT. Funkcja extractscopes/1 parsuje scope'y w formacie .tag: i konwertuje je na atomy. Podpis tokena jest weryfikowany, ale w konfiguracjach IdP, gdzie treść scope jest kontrolowana przez użytkownika, każde logowanie z nową wartością tagu wycieka jeden atom.

RabbitMQ w wersjach od 4.0.0 do 4.3.3, 4.2.9, 4.1.14 i 4.0.23 ma podatność w AMQP 1.0, gdzie endpoint GET /bindings w zarządzaniu ujawnia pełną topologię bindingów każdemu uwierzytelnionemu użytkownikowi AMQP bez sprawdzania uprawnień do zasobów. W przeciwieństwie do innych operacji w tym samym module, GET /bindings nie sprawdza uprawnień i zwraca listę bindingów bez zmian.

Zammad przed wersją 7.0.2 zawiera podatność, która pozwala użytkownikowi z uprawnieniami edytora w jednej kategorii bazy wiedzy na zobaczenie tytułów odpowiedzi i znaczników czasu aktualizacji z kategorii, do których nie ma dostępu, poprzez globalne szybkie wyszukiwanie. Nazwy kategorii nie są ujawniane, ale tytuły mogą zawierać wrażliwe informacje.

W Zammad przed wersją 7.0.2 występuje problem z kontrolą uprawnień w obszarze zarządzania bazą wiedzy. W pewnych warunkach walidacja danych dla powiązanych elementów nie była w pełni egzekwowana, co mogło pozwolić użytkownikom z ograniczonymi uprawnieniami odczytu na interakcję z elementami poza ich zakresem dostępu.

W Zammad przed wersją 7.0.2 klient mogący wyświetlić zgłoszenie nie widzi wewnętrznych artykułów przez API listy artykułów, ale może bezpośrednio pobrać załącznik należący do wewnętrznego artykułu przez endpoint pobierania załączników. Endpoint ten sprawdza tylko nadrzędne zgłoszenie, a nie artykuł, co omija autoryzację na poziomie artykułu.

Readwise Reader dla Androida używa konfiguracji sanitize-html, która zezwala na wszystkie atrybuty w elementach SVG i PATH z powodu reguły wildcard. Ta konfiguracja nie usuwa atrybutów zdolnych do wykonywania skryptów, takich jak event handlery (np. 'onload', 'onerror'). Atakujący może dostarczyć dokument z złośliwą zawartością SVG, która przetrwa sanityzację i wykona skrypt w WebView, co prowadzi do XSS po stronie klienta.

Readwise Reader dla Androida konstruuje URL-e w WebView przy użyciu kontrolowanych przez atakującego metadanych bez odpowiedniego kodowania lub escapowania. Aplikacja interpoluje niezaufane wartości bezpośrednio do stringów URL i wstawia je do DOM przez innerHTML. Ponieważ interpolacja odbywa się bez kodowania kontekstu HTML lub JavaScript, spreparowana wartość metadanych może wyrwać się z zamierzonej struktury URL i wstrzyknąć skrypt.

Podatność XSS w aplikacji Readwise Reader dla Androida, wynikająca z braku sanityzacji HTML w przetwarzaniu metadanych importowanych dokumentów. Pola kontrolowane przez atakującego, takie jak metadane autora, są wstawiane do WebView przez innerHTML, umożliwiając trwały XSS, który wykonuje się na zsynchronizowanych urządzeniach podczas otwierania złośliwego dokumentu.

W smart kontrakcie Rattadan Cosmowarp przed wersją 56c6147 występuje porównanie do niezamierzonej wartości current_admin. Może to prowadzić do nieprawidłowego działania logiki kontraktu.