Katalog podatności CVE

IBM Concert w wersjach od 1.0.0 do 3.0.0 jest podatny na niewłaściwą kontrolę dostępu, co pozwala nieautoryzowanym użytkownikom na modyfikację plików aplikacji.

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 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.

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 projekcie sfturing hosp_order wykryto podatność w nieznanej funkcji pliku ssm_pro/src/main/java/cn/sfturing/web/CommonUserController.java. Manipulacja prowadzi do podatności cross-site request forgery, a atak można przeprowadzić zdalnie. Exploit został publicznie ujawniony i może być wykorzystany.

W podsystemie system-job Ansible Automation Platform automation-controller występuje wada wstrzykiwania argumentów. Endpoint uruchamiania szablonu system-job przechowuje zmienną "days" bez walidacji liczbowej, a dyspozytor spłaszcza listę argumentów polecenia zarządzającego w jeden ciąg ze spacjami, przez co spacje stają się dodatkowymi argumentami. Uwierzytelniony użytkownik z uprawnieniami superużytkownika może wstrzyknąć dowolne argumenty, w tym opcję ścieżki Pythona, do procesu awx-manage.