Katalog podatności CVE

W pakiecie @backstage/plugin-auth-backend-module-cloudflare-access-provider od wersji 0.1.0 do 0.5.0 występuje niewystarczająca walidacja audiencji w dostawcy uwierzytelniania Cloudflare Access. Użytkownik z ważnym tokenem dla innej aplikacji Access w tym samym zespole Zero Trust może uwierzytelnić się w Backstage. Problem naprawiono w wersji 0.5.0.

W pakiecie @backstage/plugin-proxy-backend od wersji 0.5.0 do 0.6.18 występuje niespójne egzekwowanie poświadczeń dla nakładających się tras proxy. Gdy trasa nadrzędna zezwala na dostęp nieuwierzytelniony, a trasa zagnieżdżona wymaga poświadczeń, nieuwierzytelniony użytkownik może dotrzeć do zagnieżdżonego upstreamu. Problem naprawiono w wersji 0.6.18.

Pakiet @backstage/plugin-techdocs-node od wersji 0.11.12 do 1.14.7 i 1.15.5 ma nieprawidłową walidację konfiguracji wtyczki mkdocs w TechDocs. Uwierzytelniony atakujący kontrolujący repozytorium źródłowe TechDocs może spowodować, że kompilacja dokumentacji pobierze i opublikuje dane z lokalizacji sieciowych osiągalnych dla środowiska kompilacji.

W loaderze plików DirectDraw Surface (DDS) w GIMP występuje przepełnienie bufora na stercie. Przy wczytywaniu spreparowanego obrazu DDS obliczenia rozmiaru bufora na podstawie szerokości, wysokości i pitch mogą przepełnić 32-bitową arytmetykę, przez co alokowany bufor jest za mały dla zapisywanych danych pikseli przez GEGL. Może to prowadzić do uszkodzenia sterty, a w najgorszym przypadku do wykonania dowolnego kodu w kontekście procesu GIMP.

W Amazon Bedrock AgentCore Starter Toolkit przed wersją 0.3.14 występuje podatność na SSRF w przetwarzaniu schematu OpenAPI w funkcji importu agenta. Uwierzytelniony zdalny aktor w tym samym koncie AWS może spowodować, że środowisko użytkownika importującego agenta wyśle dowolne żądania wychodzące i odczyta dowolne pliki lokalne. Problem naprawiono w wersji 0.3.14, a zalecane jest przejście na @aws/agentcore.

Niewłaściwa kontrola generowania kodu w funkcji importu agentów w Amazon Bedrock AgentCore Starter Toolkit przed wersją 0.3.14 może pozwolić uwierzytelnionemu aktorowi z tego samego konta na wykonanie dowolnego kodu, gdy użytkownik importuje i uruchamia lub wdraża Agenta Bedrock, poprzez spreparowane wartości konfiguracyjne osadzone w wygenerowanym kodzie Pythona bez bezpiecznego kodowania literałów.

W opcjonalnym przykładzie hooka Lambda dla Amazon Q Business (q-business-lambda-hook) dostępnym z QnABot on AWS w wersjach 7.0.0 do 7.4.5 występuje obejście autoryzacji przez klucz kontrolowany przez użytkownika. Uwierzytelniony zdalny użytkownik może odczytać dowolne obiekty S3 w koncie AWS. Problem naprawiono w wersji 7.4.6, ale wymaga ponownego wdrożenia stosu hooka.

W SSSD (System Security Services Daemon) występuje wada polegająca na tym, że żądania przed uwierzytelnieniem zachowują stan w pamięci bez jego czyszczenia lub limitowania czasu. Lokalny atakujący może wielokrotnie inicjować przepływy uwierzytelniania bez ich kończenia, powodując nieograniczone zużycie pamięci, co może prowadzić do DoS.

W SSSD występuje wada polegająca na wyścigu w responderze autofs między zakończeniem asynchronicznego wyliczania a unieważnieniem mapy. Lokalny użytkownik może wielokrotnie wysyłać równoczesne żądania wyliczania i unieważniania map, powodując wyciek pamięci i nadmierne zużycie pamięci, co może zakłócić lub zatrzymać usługę autofs.

Luka w Ghostscript pozwala na obejście sandboxa -dSAFER i wykonanie dowolnych poleceń powłoki w kontekście procesu Ghostscript podczas renderowania spreparowanego dokumentu PostScript lub EPS. Luka łączy uszkodzenie pamięci podczas parsowania dokumentu z wyłączeniem wewnętrznych kontroli dostępu do ścieżek w czasie działania.

Podczas transferu prywatnego repozytorium do użytkownika bez dostępu, Gitea przyznaje mu tymczasowy dostęp do odczytu jako współpracownikowi. Odrzucenie lub anulowanie transferu nie cofało tej współpracy, więc odbiorca zachowywał trwały dostęp do odczytu do prywatnego repozytorium, w tym do kodu, zgłoszeń, pull requestów i wiki, oraz mógł je klonować. Właściciel repozytorium nie był powiadamiany. Dostęp przyznany przez transfer jest teraz usuwany, a współprace istniejące przed transferem są zachowywane.

Gitea rozszerza statyczną macierz `strategy.matrix` w przepływie pracy do pełnego iloczynu kartezjańskiego bez limitu rozmiaru podczas tworzenia przebiegu, przed zastosowaniem bramki zatwierdzania pull requestów z forka. Użytkownik, który może otworzyć pull request z forka, może przesłać mały plik przepływu pracy, którego macierz rozszerza się do bardzo dużej liczby zadań, zużywając pamięć serwera i potencjalnie kończąc proces Gitea. Nie jest wymagany runner. Macierze statyczne powyżej 256 kombinacji są teraz odrzucane przed rozszerzeniem.

Gdy instalator internetowy Gitea jest dostępny dla bazy danych, która już zawiera użytkowników, na przykład po zresetowaniu `INSTALL_LOCK` do `false`, przesłanie formularza instalacji z nazwą administratora pasującą do istniejącego konta wydawało uwierzytelnioną sesję dla tego konta bez weryfikacji hasła. Jeśli konto jest administratorem, sesja daje pełny dostęp administracyjny, w tym możliwość zmiany hasła konta. Bazy danych z jednym użytkownikiem również nie wymagały potwierdzenia ponownej instalacji.

Przy ustawieniu `[migrations] ALLOWED_DOMAINS` na pasujący wpis, taki jak `*` lub wildcard nazwy hosta, walidacja adresów URL migracji w Gitea mogła zezwalać na adresy zastrzeżone i link-local, takie jak `169.254.169.254`, nawet gdy `ALLOW_LOCALNETWORKS = false`. Lista blokowania sieci lokalnych nie obejmowała tych zakresów, a nazwa hosta pasująca do listy dozwolonych była akceptowana niezależnie od jej rozwiązanego adresu. Użytkownik, który może rozpocząć migracje na takiej instancji, mógł dotrzeć do tych adresów z serwera Gitea; domyślna pusta konfiguracja `ALLOWED_DOMAINS` nie jest dotknięta.

Wyrażenie regularne zewnętrznego trackera problemów repozytorium zawierające naprzemienne grupy przechwytujące mogło generować nieprawidłowe indeksy wycinka podczas renderowania odniesień do problemów w Gitea, powodując błąd runtime, który kończył proces Gitea. Użytkownik, który może edytować ustawienia zewnętrznego trackera problemów repozytorium, mógł sprawić, że późniejsze renderowanie pasującej treści, takie jak przeglądanie README, spowoduje awarię instancji dla wszystkich użytkowników.

Podczas przetwarzania treści zgłoszeń i komentarzy, Gitea skanował cały poprzedzający tekst w poszukiwaniu słów kluczowych akcji, takich jak "closes" lub "fixes", raz dla każdego linku Markdown, co dawało czas przetwarzania kwadratowy w stosunku do rozmiaru wejścia. Uwierzytelniony użytkownik mogący przesyłać treść zgłoszeń lub komentarzy mógł wysłać spreparowaną treść o rozmiarze około 1 MB, która zajmuje rdzeń CPU przez kilka minut, trzymając otwartą transakcję bazy danych.

Gitea akceptował wypchnięte drzewa Git zawierające dwa wpisy o tej samej nazwie, które własne kontrole spójności Gita odrzucają. Widoki internetowe Gitea rozwiązywały taką ścieżkę do pierwszego wpisu, podczas gdy `git checkout`, Gitea Actions i archiwa wydań używają ostatniego. Współpracownik mógł otworzyć pull request, którego diff i widoki plików pokazują nieszkodliwą treść, podczas gdy CI i checkouts w tym samym commicie używają innej, kontrolowanej przez atakującego treści. Przychodzące obiekty są teraz sprawdzane pod kątem spójności; obiekty już przechowywane w istniejących repozytoriach nie są ponownie skanowane.

Gitea Actions decydował, czy przebieg pull requesta z forka wymaga zatwierdzenia, na podstawie użytkownika, który wyzwolił zdarzenie, a nie autora pull requesta. Dla aktywności `pull_request` wyzwolonej przez opiekuna podczas zwykłego triażu, takiego jak dodanie etykiety, przebieg był tworzony bez wymagania zatwierdzenia, podczas gdy definicja przepływu pracy była nadal pobierana z głowy forka. Tam, gdzie Actions jest włączone i zarejestrowany jest pasujący runner, kod przepływu pracy kontrolowany przez fork mógł działać na runnerach bazowego repozytorium bez wyraźnego zatwierdzenia.

W Apache Commons BCEL przed wersją 6.13.0 występuje problem z mapowaniem nazw symbolicznych na klasy. BCEL buforuje klasy kontrolowane przez atakującego pod nazwami, które same deklarują, bez walidacji żądanej nazwy, co pozwala na późniejsze odwołania i wyniki weryfikacji oparte na nazwie odnosić się do innej klasy.

Gitea walidował adres zdalny mirrora push przeciwko listom dozwolonych i blokowanych `[migrations]` tylko podczas tworzenia mirrora. Każda synchronizacja przekazywała zapisany adres bezpośrednio do `git push`, więc nazwa, która później rozwiązała się na zablokowany lub wewnętrzny adres, była nadal osiągana. Użytkownik z dostępem administracyjnym do repozytorium, w tym repozytoriów, które sam tworzy, mógł skierować synchronizację mirrora push na wewnętrzne usługi Git i wymusić wypchnięcie zawartości repozytorium do nich.