Katalog podatności CVE

Wada w automation-controller platformy Ansible Automation Platform: podczas kopiowania WorkflowJobTemplate walidator uprawnień deep-copy sprawdza tylko inventory, unified_job_template i credentials, ale nie sprawdza instance_groups (oraz execution_environment i labels) zachowanych z oryginału. Użytkownik z uprawnieniami workflow-admin w organizacji, ale bez roli na odwołanych instance groups, może skopiować workflow, zostać jego administratorem i uruchamiać zadania przypięte do nieautoryzowanych instance groups, w tym do grupy control-plane, omijając granicę InstanceGroup use_role i powodując uruchomienie automatyzacji w kontekście control-plane.

W Ansible Automation Platform automation-controller w dostarczonej konfiguracji produkcyjnej kontroler ufa nagłówkowi X-Forwarded-For dostarczonemu przez klienta jako adresowi IP klienta, bez weryfikacji, że pochodzi z zaufanego proxy, i wybiera skrajną lewą (kontrolowaną przez atakującego) wartość nagłówka. Atakujący może sfałszować źródłowy adres IP zapisywany w logach audytu i dostępu kontrolera.

W Ansible Automation Platform automation-controller nieuwierzytelniony odbiornik webhooków Bitbucket Data Center pomija weryfikację podpisu HMAC dla zdarzeń diagnostics:ping po wyszukaniu docelowego szablonu, zwracając HTTP 200 dla szablonu z skonfigurowanym webhookiem Bitbucket DC i HTTP 403 w przeciwnym razie. Nieuwierzytelniony zdalny atakujący może użyć tej różnicy odpowiedzi jako wyroczni do wyliczenia identyfikatorów szablonów zadań i szablonów zadań workflow z skonfigurowanymi webhookami Bitbucket DC, bez znajomości sekretu webhook_key.

W endpointcie install-bundle kontrolera automatyzacji (automation-controller) występuje błąd walidacji nazwy hosta. Administrator systemu może zarejestrować wariant wielkości liter istniejącej nazwy hosta węzła kontrolnego i uzyskać certyfikat X.509 podpisany przez CA mesha receptor, ważny dziesięć lat, bez dziennika wydania i listy odwołań. Ponieważ walidator znaków jest niewrażliwy na wielkość liter, a walidator unikalności jest wrażliwy, certyfikat jest akceptowany przez peery TLS jako certyfikat węzła kontrolnego.

W automation-controller funkcja sanitize_jinja() używa wyrażeń regularnych, które zatrzymują się na pierwszym wewnętrznym znaku '}' lub '%', więc wyrażenie Jinja zawierające wewnętrzny nawias (np. pusty słownik) jest akceptowane, pozostając prawidłowym Jinja. Ponieważ sanitize_jinja() jest jedynym zabezpieczeniem kilku pól w czasie uruchamiania, użytkownik o niskich uprawnieniach może wstrzyknąć Jinja, którą ansible-core wykonuje w środowisku wykonawczym.

W podsystemie powiadomień automation-controller występuje luka, w której wartość odbiorcy z NotificationTemplate.notification_configuration jest kopiowana jawnym tekstem do niezabezpieczonego pola Notification.recipients przy każdym wysłaniu. Ponieważ endpoint credential-types jest dostępny dla każdego uwierzytelnionego użytkownika, a backend filtrów API przechodzi przez relacje obiektów bez autoryzacji na każdym poziomie, użytkownik bez uprawnień może użyć filtra relacyjnego jako oracle'a typu boolean do odzyskania znak po znaku sekretnych wartości odbiorców powiadomień innych najemców, w tym kluczy usług PagerDuty oraz adresów URL z tokenami bearer dla Slack, Mattermost, RocketChat i Webhook. Luka wpływa na poufność.

W API automation-controller nieuwierzytelniony endpoint health-check /api/v2/ping/ (ApiV2PingView, AllowAny) nadmiernie serializuje dane automation-mesh chronione przez RBAC do anonimowej odpowiedzi, ujawniając pełny inwentarz instancji (nazwy hostów węzłów, typy węzłów, UUID, heartbeaty, pojemności i dokładne wersje), wszystkie nazwy i członkostwo grup instancji, UUID instalacji wdrożenia oraz aktywny węzeł kontrolny. Zdalny, nieuwierzytelniony atakujący może to wykorzystać do mapowania płaszczyzny kontrolnej i fingerprintingu wersji oprogramowania w celu ukierunkowanych ataków. Luka wpływa wyłącznie na poufność; nie ujawnia sekretów, poświadczeń ani danych najemców.

W Ansible Automation Platform automation-controller wstrzykiwacz zmiennych środowiskowych niestandardowego typu poświadczeń sprawdza nazwy zmiennych względem listy blokad, która pomija zmienne przechwytujące proces, takie jak BASH_ENV, ENV, LD_PRELOAD, LD_LIBRARY_PATH, PYTHONSTARTUP i GIT_SSH_COMMAND. W połączeniu z wstrzykiwaczem plików poświadczeń uprzywilejowany użytkownik może zapisać kontrolowany przez atakującego skrypt w środowisku wykonawczym i wskazać na niego BASH_ENV.

W Red Hat Ansible Automation Platform automation-controller ustawienie formatujące komunikat logu dla błędów API 4XX jest szablonem formatu Pythona kontrolowanym przez administratora, renderowanym z obiektem użytkownika jako argumentem. Administrator może utworzyć szablon, który przechodzi od obiektu użytkownika do ustawień aplikacji i odczytuje klucz tajny Django oraz hasło do bazy danych, a sformatowana wiadomość jest zapisywana do loggera, który można przekazać do zewnętrznego agregatora logów.

W Red Hat Ansible Automation Platform automation-controller widok HTML standardowego wyjścia zadań, poleceń ad hoc, aktualizacji projektu i aktualizacji inwentarza escapuje metaznaki HTML, ale nie usuwa sekwencji ucieczki ANSI przed konwersją do HTML. Sekwencja hiperłącza ANSI OSC 8 w wyjściu jest rozwijana do kotwicy HTML, której href nie jest filtrowany pod kątem schematu ani escapowany, więc użytkownik o niskich uprawnieniach może osadzić link javascript: renderowany w odpowiedzi text/html bez Content-Security-Policy.

Klever-Go przed wersją 1.7.20 w indexer/common.go umieszcza kontrolowaną przez atakującego wartość acc.Name w żądaniu _bulk JSON i NDJSON do Elasticsearch bez escapowania. Transakcja SetAccountName akceptuje prawidłowe nazwy kont UTF-8 zawierające cudzysłowy, ukośniki odwrotne i znaki nowej linii, które mogą uszkodzić ciąg JSON, odrzucić partię lub wstrzyknąć dodatkowe akcje bulk.

Klever-Go przed wersją 1.7.20 w core/kapp/validators/validators.go Register oraz ścieżka aktualizacji walidatora w czasie działania akceptują przesłany BLSPublicKey bez walidacji krzywej, podgrupy pierwszego rzędu lub niezerowości. Gdy walidator z nieprawidłowym kluczem zostanie wybrany do grupy konsensusu, MultiSigner.Reset i ścieżka weryfikacji podpisu nie mogą zdeserializować klucza grupy i anulują slot.

W bibliotece Klever-Go przed wersją 1.7.20 funkcja Buy w module marketplace nie sprawdza flagi IsClaimed przed przyjęciem oferty. Sprzedawca może rozliczyć aukcję z ofertą oczekującą, pozostawiając zamówienie z przyszłym EndTime oraz nieaktualnymi wartościami CurrentBid i CurrentBidder. Kolejny licytujący może złożyć wyższą ofertę, zostać obciążony, a poprzedni licytujący otrzymuje zwrot, mimo że NFT zostało już dostarczone.

W Klever-Go przed wersją 1.7.20 wbudowana funkcja KleverUpdateAccountPermission autoryzuje zmianę uprawnień konta docelowego, sprawdzając kontrolowane przez atakującego vmInput.RecipientAddr zamiast uwierzytelnionego vmInput.CallerAddr. Kontrakt atakującego może wybrać konto ofiary z skonfigurowanymi uprawnieniami jako RecipientAddr, a contractHasValidPermission może zaakceptować domyślnego self-signera ofiary jako autoryzację. UpdatePermission może następnie zastąpić cały zestaw uprawnień ofiary uprawnieniami Owner dostarczonymi przez atakującego, umożliwiając kradzież zasobów lub trwałe zablokowanie konta bez klucza lub podpisu ofiary.

Wada w AWX: pole pod_spec_override w grupie kontenerów używa niekompletnej listy blokującej, która ogranicza tylko automountServiceAccountToken, umożliwiając wstrzyknięcie initContainers, nadpisań serviceAccountName i projected service account token volumes. Administrator platformy AAP może to wykorzystać do eskalacji uprawnień do dostępu na poziomie przestrzeni nazw OpenShift i eksfiltracji sekretów przestrzeni nazw.

Podatność typu untrusted search path w Plesk od wersji 18.0.34 przed 18.0.80.8 oraz od 18.0.81 przed 18.0.81.1 pozwala zdalnym uwierzytelnionym użytkownikom na wykonanie dowolnego kodu jako root poprzez rozszerzenie "Plesk RESTful API" od wersji 2.4.2 przed 2.4.7.

Nieprawidłowe przypisanie uprawnień pozwala lokalnym użytkownikom na uzyskanie poufnych informacji CalDAV/CardDAV należących do innych kont.

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.