Podatności RabbitMQ

W RabbitMQ handler otwarcia strumienia wywołuje tylko check_vhost_access, pomijając sprawdzenia limitów połączeń na węzeł/vhost/użytkownika, które rabbit_reader wykonuje dla AMQP. Uwierzytelniony najemca może całkowicie obejść skonfigurowane limity połączeń, łącząc się przez port 5552 zamiast 5672.

W RabbitMQ przed wersjami 4.2.7 i 4.3.1 funkcja rabbit_pid_codec:decompose_from_binary/1 przetwarza dostarczone przez klienta dane binarne zakodowane w ETF i wywołuje binary_to_atom(Node, utf8) na polu nazwy węzła. Jest to osiągalne z rabbit_volatile_queue:pid_from_name/2, które jest wywoływane dla każdej nazwy kolejki lub klucza routingu zaczynającego się od amq.rabbitmq.reply-to.. Sprawdzenie członkostwa w CandidateNodes następuje po utworzeniu atomu, a otaczający try/catch nie może odzyskać atomów (nigdy nie są usuwane przez GC). Każdy uwierzytelniony klient AMQP może zawiesić całą maszynę wirtualną Erlang (wszystkie vhosty, wszystkie połączenia) za pomocą około 1 miliona tanich żądań.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 funkcja parse_array_primitive/2 dla konstruktora 0x45 (list0) zwraca element o szerokości bajtowej B = 0. Otaczający parser array32 odczytuje 4-bajtowe Count z sieci i wykonuje pętlę Count razy, zużywając B bajtów za każdym razem; gdy B = 0, żadne dane wejściowe nie są konsumowane, a pętla buduje listę Count pustych elementów ograniczoną tylko 32-bitowym polem. Ramka SASL-mechanisms / SASL-init jest parsowana przez amqp10_framing:decode_bin/1 z rabbit_amqp_reader.erl:412 przed zakończeniem uwierzytelniania. Pre-auth incoming_max_frame_size (domyślnie 8192 bajty) ogranicza ramkę, a nie pole Count, więc 19-bajtowy ładunek z Count = 0xFFFFFFFF jest akceptowany. Nie ustawiono max_heap_size dla procesu czytnika. Nieuwierzytelniony atakujący sieciowy może zawiesić dowolny węzeł RabbitMQ z włączonym listenerem AMQP 1.0 (domyślny port 5672), wysyłając pojedynczą ~19-bajtową ramkę.

W RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11, 4.2.6 i 4.3.0 handler /api/queues/quorum/:vhost/:queue/status odczytuje vhost ze ścieżki bez sprawdzenia dostępu użytkownika, używając is_authorized/2 zamiast is_authorized_vhost/2. Użytkownik z tagiem management może odczytać status Raft dla kolejek kworum w niedostępnych vhostach.

W RabbitMQ przed wersjami 3.13.17, 4.0.22, 4.1.13 i 4.2.6 funkcja match_origin/1 zwracała odbity Origin i zezwalała na poświadczenia nawet gdy skonfigurowano wildcard "*", więc odpowiedź odbijała origin atakującego wraz z Access-Control-Allow-Credentials. Dotyczy to kodu rabbit_mgmt_cors.erl. Gdy wtyczka zarządzania jest skonfigurowana z wildcard CORS origin (cors_allow_origins = "*"), handler odbija Origin żądania w Access-Control-Allow-Origin i wysyła Access-Control-Allow-Credentials: true. Złośliwa strona internetowa, którą odwiedza zalogowany administrator, może następnie użyć jego buforowanych poświadczeń HTTP Basic do wysyłania uwierzytelnionych żądań zmieniających stan do API zarządzania.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 nie sprawdza autoryzacji dla pasywnych operacji queue.declare i exchange.declare w protokole AMQP 0-9-1. Umożliwia to każdemu uwierzytelnionemu użytkownikowi podłączonemu do wirtualnego hosta na wyliczenie nazw kolejek i wymian oraz odczytanie liczby wiadomości i konsumentów.

RabbitMQ przed wersją 4.2.6 nie egzekwuje limitu rozmiaru ramek strumieniowych podczas składania ramek w trakcie uwierzytelniania i przed negocjacją Tune. Pozwala to nieuwierzytelnionemu zdalnemu klientowi deklarować nadmierne rozmiary ramek i konsumować pamięć brokera w komponencie rabbit_stream_core.

Podatność w RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 pozwala nieuwierzytelnionym atakującym na odczytanie sekretu klienta OAuth 2 poprzez przestarzały endpoint GET /api/auth. Problem występuje, gdy włączona jest wtyczka zarządzania i skonfigurowane management.oauth_client_secret.

Podatność w RabbitMQ przed wersją 4.2.6 umożliwia istniejącemu konsumentowi dalsze odbieranie wiadomości po wygaśnięciu tokena OAuth lub odświeżeniu connection.update_secret do zawężonych zakresów. Dzieje się tak, ponieważ istniejący konsumenci nie są anulowani ani ponownie autoryzowani w momencie dostarczania wiadomości po zmianie stanu użytkownika kanału.

Podatność w RabbitMQ dotyczy autoryzacji tematów (topic authorization), która podczas błędów magazynu metadanych może zezwalać na nieautoryzowane zapisy i wiązania tematów. Błąd wynika z tego, że błędy wyszukiwania uprawnień tematów w Khepri są interpretowane jako 'undefined', co wewnętrzny backend traktuje jako zezwolenie.

Podatność w RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 umożliwia użytkownikowi z ograniczeniem do pętli zwrotnej (np. guest) zdalne uwierzytelnienie, gdy ruch jest akceptowany przez zaufaną ścieżkę PROXY, a backend nasłuchuje na pętli zwrotnej. Problem wynika z błędnego sprawdzania adresu gniazda nasłuchującego zamiast rzeczywistego źródła klienta.

RabbitMQ przed wersjami 3.13.15, 4.0.20, 4.1.11 i 4.2.6 umożliwia tworzenie zewnętrznych powiązań do kolejek amq.rabbitmq.reply-to. Luka wynika z braku sprawdzania ulotnych kolejek direct-reply-to podczas usuwania powiązań w systemie Khepri, co pozostawia trwałe wpisy tras.

Podatność XSS w interfejsie zarządzania RabbitMQ pozwala użytkownikowi z uprawnieniami do deklarowania kolejek lub giełd na wykonanie kodu JavaScript w przeglądarce innego użytkownika. Problem występuje przed wersją 4.2.5 i dotyczy nieprawidłowego escapowania argumentu x-internal-purpose w atrybucie title HTML.

Wtyczka rabbitmq_federation_management w RabbitMQ przed wersjami 3.13.14, 4.0.19, 4.1.10 i 4.2.5 nie koduje pola consumer_tag na stronie statusu federacji, co umożliwia atak XSS. Użytkownik z uprawnieniami do konfiguracji upstream lub polityki federacji może wstrzyknąć kod JavaScript, który wykona się w przeglądarce administratora przeglądającego tę stronę.

RabbitMQ przed wersjami 3.13.14, 4.0.19, 4.1.10 i 4.2.5 zawiera podatność w interfejsie HTTP API rabbitmq_management, która pozwala na akceptowanie zbyt dużych poprawnych ciał JSON na ścieżkach with_decode i direct_request. Problem wynika z nieprawidłowego sprawdzania rozmiaru w funkcji read_complete_body, która uwzględnia rozmiar przed ostatnim fragmentem, ale nie końcowy łączny rozmiar.

Podatność w RabbitMQ na Windows przed wersjami 4.1.11 i 4.2.6 pozwala na przekazanie zakodowanych w URL backslashy do handlera plików statycznych przed walidacją ścieżki, gdy włączonych jest wiele rozszerzeń zarządzania. Skutkuje to wysyłaniem żądań DNS i SMB do kontrolowanych przez atakującego ścieżek UNC.