Podatności RabbitMQ

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.