Podatności RabbitMQ

W wersjach RabbitMQ 3.4.x, 3.5.x oraz 3.6.x przed 3.6.9, a także w wersjach RabbitMQ dla PCF 1.5.x, 1.6.x przed 1.6.18 oraz 1.7.x przed 1.7.15, zidentyfikowano problem związany z przechowywaniem danych uwierzytelniających użytkowników w lokalnej pamięci przeglądarki bez daty wygaśnięcia. Umożliwia to ich odzyskanie w wyniku skoordynowanego ataku.

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.