Katalog podatności CVE

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 nie weryfikuje nagłówka Origin podczas uaktualnienia WebSocket w handlerach Web-MQTT i Web-STOMP. Przy włączonym ssl_cert_login=true przeglądarka automatycznie przedstawia certyfikat klienta, więc złośliwy JavaScript w przeglądarce ofiary może uwierzytelnić się jako ofiara.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 — gdy brak jest pakietu CA, ssl_options/1 domyślnie używa [{verify, verify_none}] bez ostrzeżenia. Atakujący w pozycji man-in-the-middle może sfałszować odpowiedź JWKS, co prowadzi do akceptacji dowolnych tokenów JWT przez brokera.

RabbitMQ przed wersjami 4.2.7 i 4.3.1 nie nakłada jawnego limitu dopasowań podczas kompilacji wzorców LIKE do wyrażeń regularnych, co pozwala uwierzytelnionemu konsumentowi AMQP 1.0 z uprawnieniami odczytu i zapisu na kolejce strumieniowej wywołać znaczne zużycie CPU poprzez spreparowany filtr LIKE. Każda dostarczona wiadomość może powodować około 100-200 ms obciążenia CPU, co przy tysiącach wiadomości i równoległych sesjach daje amplifikację. Problem został naprawiony w wersjach 4.2.7 i 4.3.1.

RabbitMQ przed wersjami 4.3.0, 4.2.6, 4.1.11, 4.0.20 i 3.13.15 przechowuje wartość BodySize z nagłówka content-header bez walidacji względem max_message_size. Klient może zadeklarować body_size = 2^63-1 i strumieniować fragmenty, przez co kontrola rozmiaru nigdy się nie uruchamia, a proces czytający gromadzi nieograniczoną ilość pamięci. Prowadzi to do wyczerpania pamięci węzła lub alarmu pamięciowego i degradacji wszystkich wydawców w klastrze.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 włącza kompresję permessage-deflate w WebSocket (RFC 7692) bez limitu rozmiaru ramki i bez limitu rozmiaru wyjściowego dekompresji. Nieuwierzytelniony atakujący może wysłać silnie skompresowaną ramkę WebSocket (tzw. bombę zlib), która po dekompresji zajmuje gigabajty pamięci, powodując awarię węzła RabbitMQ z włączoną wtyczką Web-MQTT.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 — plugin trust-store instaluje verify_fun, który nadpisuje błędy {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer}, gdy prezentowany certyfikat „pasuje” do białej listy. Klucz dopasowania opiera się wyłącznie na nazwie wystawcy i numerze seryjnym, które można łatwo podrobić, co pozwala na obejście uwierzytelniania klienta TLS.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 wywołuje rabbit_data_coercion:atomize_keys/1 (niebezpieczny wariant używający binary_to_atom) na mapie metadanych vhosta. Administrator importujący spreparowany plik definicji może wyczerpać tablicę atomów i zawiesić węzeł w jednym żądaniu.

RabbitMQ przed wersjami 4.2.7 i 4.3.1 w ścieżce wyszukiwania parametrów runtime konwertuje segment :component z URL na atom za pomocą rabbit_data_coercion:to_atom/1, tworząc nowy atom dla każdej nieznanej wartości. Uprawniony policymaker może wysłać około miliona żądań z różnymi wartościami component, wyczerpując tablicę atomów i zawieszając węzeł.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.1 konsument trace tworzy ścieżkę wyjściową bez sprawdzenia bezpieczeństwa ścieżki względnej, mimo że strona odczytu takie sprawdzenie wykonuje. Administrator może poprzez parametr name zapisać plik z rozszerzeniem .log w dowolnej lokalizacji zapisywalnej przez użytkownika rabbitmq, np. /etc/cron.d/x.log.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0: shovel AMQP 0-9-1 usuwa poświadczenia przed zapisaniem URI połączenia, ale shovel AMQP 1.0 przechowuje surowy URI zawierający hasło. Zapisany URI jest widoczny przez GET /api/shovels oraz rabbitmqctl shovel_status.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0: przy tworzeniu bindingu na wymianie x-jms-topic funkcja add_binding/3 odczytuje argument rjms_erlang_selector i przetwarza go przez erl_scan:string/1 oraz erl_parse:parse_term/1. erl_scan:string/1 internuje każdy atom, a validate_binding/2 jest no-op bez limitu długości. Uwierzytelniony użytkownik AMQP o niskich uprawnieniach może zawiesić cały węzeł brokera w mniej niż 100 wywołaniach bind.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0: add_binding/3 parsuje klucz routingu jako całkowitą wagę N i oblicza pozycje pierścienia przez lists:seq(NextN0, NextN0 + N - 1). validate_binding/2 sprawdza tylko N >= 1, bez górnego limitu. Użytkownik z uprawnieniami zapisu na wymianie consistent-hash może utworzyć binding z ogromną wagą, alokując setki megabajtów na każdym węźle klastra.

W RabbitMQ przed wersjami 4.0.22, 4.1.11, 4.2.6 i 4.3.0 handler HTTP accept_content/2 wywołuje create_super_stream bez wymaganego sprawdzenia uprawnień configure na wymianie i kolejkach partycji, które jest obecne w ścieżce protokołu strumieniowego. Użytkownik z tagiem management i dostępem do vhosta, ale bez uprawnień configure, może tworzyć super-strumienie przez API HTTP.

RabbitMQ przed wersjami 4.1.11, 4.2.6 i 4.3.0: validate_partitions sprawdza tylko, że żądana liczba partycji wynosi co najmniej 1, bez górnego limitu. Duża wartość, np. lists:seq(0, 500000000), alokuje około 8 GB pamięci.

W interfejsie zarządzania RabbitMQ (wersje przed 3.13.15, 4.0.20, 4.1.11 i 4.2.6) dane z certyfikatu klienta TLS, takie jak Subject i Issuer DN, są wyświetlane bez escapowania HTML. Podatność występuje, gdy listener TLS ma włączoną opcję verify_peer, a atakujący posiada certyfikat klienta podpisany przez zaufany urząd CA z dowolnym Subject CN. Administrator przeglądający szczegóły takiego połączenia w panelu może stać się ofiarą ataku XSS, co prowadzi do przejęcia jego sesji.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.1 trasa /federation-links/.../restart używa is_authorized_monitor akceptującego tag monitoring, a DELETE wywołuje restart łącza federacji bez sprawdzenia podniesionych uprawnień. Użytkownik z tagiem monitoring może zrestartować dowolne łącze federacji.

W RabbitMQ funkcja match_value/3 przekazuje dostarczone przez użytkownika wyrażenie regularne ?name= do re:run bez opcji match_limit i wykonuje je raz na każdy zasób w wyniku. Przy dużym zbiorze zasobów pojedyncze żądanie może zużyć wiele minut CPU, a równoległe żądania wysycają schedulery. Ścieżka jest osiągalna przez normalne użycie API z opcją use_regex=true.

W RabbitMQ funkcja get_chunk_selector/1 wywołuje binary_to_atom na surowej właściwości <<"chunk_selector">> dostarczonej przez klienta w ramkach subscribe i resolve_offset_spec, bez białej listy i bez istniejącej walidacji. Uwierzytelniony klient strumienia z prawem odczytu dowolnego strumienia może zawiesić węzeł brokera.

W RabbitMQ przed wersjami 4.1.13, 4.2.7 i 4.3.0 is_authorized/2 używa is_authorized_monitor dla wszystkich metod, a DELETE resetuje liczniki prób uwierzytelnienia. Użytkownik z tagiem monitoring może wyzerować te liczniki przez DELETE /api/auth/attempts/:node, usuwając dowody aktywności brute-force.

W RabbitMQ makro ?LOG_DEBUG formatuje całą mapę stanu Shovel, w tym pole 'uris' zawierające odszyfrowane URI z poświadczeniami. Przy włączonym logowaniu DEBUG zakończenie autodelete shovela zapisuje pełną mapę stanu, w tym amqp://user:password@host/, do pliku logu brokera.