Katalog podatności CVE

Gitea Actions blokuje zadania przebiegów workflow z pull requestów od pierwszego kontrybutora z forka, dopóki opiekun nie zatwierdzi przebiegu. Ścieżka ponownego uruchomienia wymagała tylko, aby przebieg był zakończony, i budowała zadania nowej próby bez uwzględnienia oczekującego zatwierdzenia, więc gdy użytkownik z uprawnieniami zapisu do Actions anulował przebieg oczekujący na zatwierdzenie, a następnie uruchomił go ponownie, nowe zadania zostały utworzone jako oczekujące, a nie zablokowane, podczas gdy przebieg nadal rejestrował, że wymagane jest zatwierdzenie. Anulowanie i ponowne uruchamianie starych kontroli z forka jest rutynową czynnością, która nie obejmuje kontroli zatwierdzenia, więc tam, gdzie Actions jest włączone i zarejestrowany jest pasujący runner, kod workflow pobrany z głowy pull requesta z forka może zostać uruchomiony na runnerach repozytorium bez wyraźnego zatwierdzenia.

Użytkownik, który może otworzyć pull request z forka, może umieścić treść workflow ze współdzieloną grupą współbieżności na poziomie przebiegu w przebiegu Gitea Actions oczekującym na zatwierdzenie. Gdy późniejszy przebieg w tej grupie anuluje zablokowane zadanie, przebieg staje się terminalny, ale nadal oznaczony jako wymagający zatwierdzenia. Jeśli opiekun później zatwierdzi przebieg, Gitea przekazał już anulowane zadanie z powrotem przez przygotowanie współbieżności, ustawił je na oczekujące i umożliwił przejęcie przez pasujący runner, wykonując kod workflow kontrolowany przez fork. Wykorzystanie wymaga późniejszego zatwierdzenia przez opiekuna, włączonych Actions i runnera akceptującego zadania repozytorium.

W SSSD wykryto lukę w środowiskach zarządzania tożsamością z włączonym zaufaniem. SSSD ocenia reguły Host-Based Access Control (HBAC), usuwając kwalifikatory domeny i porównując tylko krótkie nazwy użytkowników. Uwierzytelniony użytkownik w zaufanej domenie o tej samej nazwie co autoryzowane konto lokalne może obejść polityki dostępu i uzyskać nieautoryzowany dostęp do chronionych usług lub hostów.

W SSSD wykryto lukę w konfiguracji z Microsoft Entra ID. Dane wejściowe wyszukiwania nie są prawidłowo sanityzowane przed włączeniem ich do filtrów zapytań katalogowych. Lokalny użytkownik może wykorzystać tę podatność, wysyłając spreparowane żądanie wyszukiwania, manipulując logiką zapytania i powodując nieautoryzowane ujawnienie informacji z katalogu.

Gdy wstawiano przebieg Gitea Actions, starsze przebiegi w tej samej grupie współbieżności na poziomie workflow były anulowane bez sprawdzania, czy nowy przebieg nadal wymaga zatwierdzenia. Ponieważ przebiegi z pull requestów z forków są wstawiane pod repozytorium bazowym, użytkownik, który może otworzyć pull request z forka, może anulować zaufane trwające przebiegi, które dzielą grupę współbieżności z włączoną opcją `cancel-in-progress`, bez zatwierdzenia i bez uruchamiania żadnego kodu. Na self-hosted runnerach może to przerwać wdrożenia i pozostawić częściowy stan.

Rejestr kontenerów Gitea serwował pobieranie blobów z `Content-Type` pobranym z typu mediów zadeklarowanego w wypchniętych manifestach obrazów, bez `Content-Disposition` ani restrykcyjnej polityki bezpieczeństwa treści. Użytkownik, który może wypychać obrazy kontenerów, może opublikować blob zawierający HTML i JavaScript z typem mediów `text/html`. Gdy ofiara uwierzytelniona w instancji otworzy URL bloba w przeglądarce, skrypt uruchamia się na originie Gitea i może wykonywać działania jako ofiara, takie jak tworzenie tokenów API.

Zmiana uprawnień zespołu organizacji przez API z tylko polem `permission` nie odbudowywała dostępu per-jednostka zespołu, a żądany poziom nie był stosowany jako limit. Po tym, jak właściciel organizacji zdegradował zespół, na przykład z admina do read, członkowie zespołu zachowali poprzednie uprawnienia jednostek, w tym dostęp do zapisu do repozytoriów zespołu. Formularz internetowy nie był dotknięty.

Gdy wbudowany serwer SSH Gitea jest włączony (`START_SSH_SERVER = true`), prezentowany klucz publiczny był wyszukiwany za pomocą porównania SQL `LIKE` jego zakodowanej treści, które jest niewrażliwe na wielkość liter na niektórych bazach danych, w tym domyślnym SQLite. Atakujący, który może skonstruować wariant wielkości liter zarejestrowanego klucza publicznego RSA innego użytkownika, dla którego może wyprowadzić klucz prywatny, może spowodować dopasowanie tego klucza do konta ofiary i uwierzytelnić się przez SSH jako ten użytkownik. Klucze są teraz wyszukiwane po odcisku palca.

Elasticsearch zawiera podatność polegającą na obejściu autoryzacji w modelu Remote Cluster Security (RCS) 2.0. Atakujący z ważnym kluczem API może wysłać specjalnie spreparowane żądanie cross-cluster search, które autoryzuje dostęp do jednego indeksu, ale faktycznie operuje na innym, nieautoryzowanym indeksie, ujawniając jego dane.

Podatność typu niekontrolowana rekurencja (CWE-674) w Elasticsearch może prowadzić do odmowy usługi poprzez specjalnie spreparowane żądanie powodujące przetwarzanie głęboko zagnieżdżonej struktury danych bez ograniczenia głębokości rekurencji. Elasticsearch ma tę słabość w budowaniu i serializacji wartości geometrii tworzonych przez skryptowe pola runtime. Uwierzytelniony użytkownik z dostępem do odczytu jednego indeksu może wysłać żądanie definiujące takie pole ze skryptem tworzącym głęboko zagnieżdżoną strukturę, co powoduje przekroczenie stosu i zakończenie działania węzła. Węzeł nie zawsze odzyskuje sprawność automatycznie i może wymagać ręcznej interwencji.

Elasticsearch zawiera podatność nieprawidłowej autoryzacji w opcjonalnym uprawnieniu delegowanym, które pozwala administratorowi na ograniczone zarządzanie rolami. Z powodu niepełnego egzekwowania zakresu, użytkownik z tym uprawnieniem może rozszerzyć swój dostęp do indeksów, które powinny pozostać ograniczone, w tym do wewnętrznych danych bezpieczeństwa.

Podatność typu niekontrolowana rekurencja (CWE-674) w Elasticsearch może prowadzić do odmowy usługi poprzez specjalnie spreparowane, głęboko zagnieżdżone żądanie wysłane do funkcji agregacji API wyszukiwania. Elasticsearch ma tę słabość w przetwarzaniu agregacji wyszukiwania. Uwierzytelniony użytkownik z dostępem do odczytu jednego indeksu może wysłać spreparowane żądanie z głęboko zagnieżdżonymi definicjami agregacji, co wyczerpuje zasoby procesu serwera i powoduje zakończenie działania węzła. Węzeł nie odzyskuje sprawności automatycznie i wymaga ręcznej interwencji.

Podatność typu alokacja pamięci z nadmierną wartością rozmiaru (CWE-789) w Elasticsearch może prowadzić do odmowy usługi poprzez nadmierną alokację (CAPEC-130). Uwierzytelniony użytkownik z uprawnieniami do zarządzania konektorami może spowodować, że klaster przydzieli niekontrolowaną ilość pamięci, gdy tworzone są zasoby konektorów z nadmiernie dużym polem `description`, a następnie są one dostępne, co wyczerpuje dostępną pamięć sterty i powoduje awarię węzła.

Podatność typu nieobsłużony wyjątek (CWE-248) w Elastic Endpoint może prowadzić do odmowy usługi poprzez specjalnie spreparowaną nazwę pliku. Gdy komponent Elastic Endpoint w Elastic Defend przetwarza nazwę pliku w pewnych konfiguracjach ustawień regionalnych systemu (w tym chińskich, japońskich i koreańskich) w Windows, podczas obsługi ścieżki pliku może wystąpić nieobsłużony wyjątek. Powoduje to wielokrotne awarie i restarty procesu Elastic Endpoint, co może osłabić lub wyłączyć funkcje zapobiegania złośliwemu oprogramowaniu w czasie rzeczywistym i wykrywania behawioralnego na dotkniętym hoście, dopóki warunek nie ustąpi.

Nieprawidłowa autoryzacja w Kibanie umożliwia ujawnienie poufnych informacji. Uwierzytelniony użytkownik z ograniczonymi uprawnieniami Fleet może uzyskać dostęp do materiałów poświadczających, które powinny być zarezerwowane dla administratorów. Wykorzystanie luki może pozwolić na kradzież kluczy kryptograficznych i podszywanie się pod zaufane komponenty infrastruktury Fleet.

Elasticsearch nie ogranicza całkowitej pamięci używanej przy pobieraniu wielu szablonów indeksów, mimo limitów dla pojedynczych zasobów. Użytkownik z uprawnieniem manage_index_templates może zarejestrować wiele szablonów, a ich jednoczesne pobranie powoduje wyczerpanie pamięci i awarię węzła. Prowadzi to do odmowy usługi.

Brak autoryzacji w Kibanie w funkcji Metrics Experience umożliwia użytkownikowi z dostępem tylko do odczytu danych na poziomie indeksu pobieranie danych metrycznych przez Kibana, mimo braku odpowiedniego uprawnienia funkcji Kibana. Odpowiednik API z tą samą funkcją wymagał autoryzacji, ale to wewnętrzne API jej nie egzekwowało.

Nieograniczona rekurencja w Elasticsearch pozwala uwierzytelnionemu użytkownikowi z niskimi uprawnieniami na zakończenie działania węzła Elasticsearch, powodując odmowę usługi. Podatność jest związana z nadmierną alokacją zasobów.

Nieskuteczna złożoność wyrażeń regularnych w Elasticsearch w funkcji ES|QL CHUNK umożliwia odmowę usługi przez katastrofalne cofanie się. Użytkownik z dostępem do odczytu do indeksu tekstowego może przesłać specjalnie spreparowane wyrażenie regularne, które powoduje nadmierne zużycie CPU i degradację wydajności zapytań dla innych dzierżawców.

Nieprawidłowa autoryzacja w Elasticsearch umożliwia uwierzytelnionemu użytkownikowi z uprawnieniami do pojedynczego zasobu modyfikację strumienia danych, do którego nie ma autoryzacji. Może to pozwolić na wstrzyknięcie danych lub zakłócenie wyszukiwania, ale nie umożliwia odczytu zawartości strumienia.