Katalog podatności CVE

W RabbitMQ Management, gdy włączony jest interfejs OAuth, powód błędu autoryzacji AMQP zawierający nazwę kolejki kontrolowaną przez atakującego jest renderowany jako HTML. Nazwa kolejki z elementem base może przekierować automatyczne odświeżanie, a przez CORS atakujący może przechwycić nagłówek Authorization administratora.

RabbitMQ w wersjach od 3.13.0 do 3.13.19, 4.0.24, 4.1.15, 4.2.10 i 4.3.5 zawiera podatność, w której odświeżenie poświadczeń OAuth utrzymuje wygasłe tagi runtime. Kiedy istniejące połączenie AMQP odświeża token OAuth z uprawnieniem impersonator na token z tą samą nazwą użytkownika, ale bez tego uprawnienia, tag 'impersonator' pozostaje w połączeniu. Dzięki temu połączenie (w tym nowo otwarte kanały) może dalej publikować wiadomości z obcym AMQP userid, mimo że powinno to być już odwołane.

Podatność w RabbitMQ przed wersją 4.3.5. Uwierzytelniony użytkownik, który może powiązać kolejkę z wymianą tematyczną i publikować do niej, może użyć kolejnych segmentów # w kluczu powiązania, co powoduje, że oba matchery tematyczne przetwarzają te same stany bez memoizacji. Skutkuje to duplikowaniem miejsc docelowych przed deduplikacją, co prowadzi do kombinatorycznego obciążenia CPU i pamięci, zakłócając routing dla wszystkich dzierżawców.

Parser parametrów Shovel w RabbitMQ konwertuje wartości parametrów kontrolowane przez atakującego na atomy Erlanga, które nie podlegają garbage collection, przed ich ograniczeniem lub sprawdzeniem dozwolonej listy. Atakujący może wyczerpać tablicę atomów węzła i spowodować odmowę usługi, a złośliwe parametry są trwale zapisywane i ponownie parsowane po restarcie.

Wtyczka rabbitmq_jms_topic_exchange w RabbitMQ przyjmuje kontrolowane przez klienta wyrażenie rjms_erlang_selector, którego ewaluator LIKE rozwija wildcardy do nakładających się fragmentów PCRE wykonywanych bez limitów dopasowania lub rekurencji. Uwierzytelniony najemca może wyczerpać CPU brokera i spowodować odmowę usługi.

Podatność w RabbitMQ od wersji 3.13.0 do 4.3.3, 4.2.9, 4.1.14, 4.0.23 i 3.13.18, polegająca na ignorowaniu kodu statusu HTTP przy pobieraniu kluczy JWKS. Mechanizm pobierania kluczy w uaajwt.erl nie sprawdza kodu odpowiedzi HTTP podczas pobierania kluczy podpisujących z punktu JWKS dostawcy OAuth2. Odpowiedzi inne niż 200 (w tym błędy 4xx i 5xx) są przetwarzane jak poprawne. Gdy punkt JWKS zwraca błąd z poprawnym JSON bez pola keys, wszystkie wcześniej zapamiętane klucze podpisujące są kasowane, co powoduje trwałą blokadę uwierzytelniania.

Podatność w RabbitMQ od wersji 4.1.0 do 4.3.3, 4.2.9 i 4.1.11, polegająca na możliwości przydzielenia dużych ilości pamięci przy niskich uprawnieniach przez zarządzanie strumieniami. Funkcja przyjmuje PUT /api/stream/super-streams/{vhost}/{name} od uwierzytelnionego użytkownika zarządzającego z dostępem do vhosta. Gdy ciało żądania zawiera pole binding-keys, handler parsuje kontrolowany przez atakującego ciąg rozdzielany przecinkami i buduje pełną listę nazw strumieni przed sprawdzeniem uprawnień. Użytkownik o niskich uprawnieniach z dostępem do vhosta może wymusić duże tymczasowe alokacje. W kontenerze z limitem pamięci 768 MB jedno żądanie HTTP PUT z ok. 4,5 MB JSON może zabić kontener.

Shovel w RabbitMQ nie formatuje stanu logowanego przez crash reporter, co może pozostawić niezaszyfrowane poświadczenia w pliku zrzutu awarii. Gdy procesy worker Shovel ulegają awarii, OTP SASL zapisuje pełny stan procesu, w tym jawnotekstowe hasła i URI AMQP, do logu błędów.

W RabbitMQ OAuth2 guard isinteger(Exp) pomija sprawdzanie wygaśnięcia tokenu dla wykładniczej wartości exp typu float. Gdy IdP wysyła exp jako float, zarówno sprawdzenie przy logowaniu, jak i timer rozłączenia są pomijane, przez co wygasły token jest akceptowany, a połączenia nigdy nie wygasają.

W RabbitMQ AMQP 1.0 management exchange.declare pomija sprawdzenie uprawnień alternate-exchange. Użytkownik z uprawnieniem configure na wymianie X może kierować jej niekierowalne wiadomości do alternate exchange, do którego nie ma uprawnień zapisu.

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.

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.

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.

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.

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.