Katalog podatności CVE

W Apache log4net w konwerterze wzorca aspnet-request występuje niewłaściwa obsługa warunków wyjątkowych. Odczyt parametrów żądania wyzwala walidację żądania ASP.NET, więc żądanie zawierające treść taką jak znaczniki powoduje wyjątek w układzie i odrzucenie całego zdarzenia przez appender. Nadawca może w ten sposób stłumić zapis własnego żądania.

Podatność w SmtpPickupDirAppender w Apache log4net wynika z nieprawidłowej obsługi kodowania Unicode. Treść, której writer nie może zakodować (np. niesparowany surogat UTF-16), powoduje wyjątek przy zapisie, w wyniku czego cała buforowana partia zdarzeń jest odrzucana, a w katalogu pickup może pozostać obcięty plik maila. Dotyczy wyłącznie aplikacji korzystających z SmtpPickupDirAppender w wersjach od 1.2.9 do 3.5.0.

Podatność w OutputDebugStringAppender w Apache log4net polega na nieprawidłowej neutralizacji znaku NUL. Znak NUL w logowanej treści kończy rekord wyjścia debugowania w tym miejscu, przez co wszystko, co layout wyrenderował po nim — w tym tekst wyjątku i pola końcowe — jest po cichu tracone. Dotyczy wyłącznie aplikacji na Windows korzystających z OutputDebugStringAppender w wersjach od 1.2.9 do 3.5.0.

Podatność w EventLogAppender w Apache log4net polega na nieprawidłowej neutralizacji znaku NUL. Znak NUL w logowanej treści kończy rekord Windows Event Log w tym miejscu, przez co wszystko, co layout wyrenderował po nim — w tym tekst wyjątku i pola końcowe — nie zostaje zapisane. Dotyczy wyłącznie aplikacji na Windows korzystających z EventLogAppender w wersjach od 1.2.9 do 3.5.0.

Podatność typu cross-site scripting (XSS) w Apache Commons BCEL wynika z nieprawidłowej neutralizacji danych wejściowych podczas generowania stron HTML. Występuje, gdy używa się Class2HTML do generowania stron dla plików klas potencjalnie kontrolowanych przez atakującego — emitery Class2HTML zapisują ciągi z plików klas do HTML bez escapowania (stored XSS w raportach). Dotyczy wersji przed 6.13.0.

Gitea sprawdza początkowy zdalny URL dla mirrorów push, zdalnych kontroli wiki i pobierania głów pull requestów migracji, ale późniejsze operacje Git podążają za przekierowaniami HTTP bez ponownej walidacji celu. Administrator repozytorium używający dozwolonego punktu końcowego, który przekierowuje, może sprawić, że klient Git Gitea wyśle żądania na adres, który polityka hostów wychodzących w przeciwnym razie zablokowałaby. Wpływ zależy od skonfigurowanej polityki i wewnętrznych usług dostępnych z serwera.

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.