Katalog podatności CVE

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.

Gdy push był uwierzytelniany kluczem wdrożeniowym, Gitea rejestrował właściciela repozytorium jako wypychającego, więc kontrole uprawnień w potoku hooka push oceniały właściciela zamiast klucza wdrożeniowego. Posiadacz zapisywalnego klucza wdrożeniowego mógł tworzyć chronione tagi bez znajdowania się na liście dozwolonych tagów i zmieniać widoczność repozytorium przez opcje push, na przykład czyniąc prywatne repozytorium publicznym. Pull requesty utworzone przez przepływ AGit z kluczem wdrożeniowym były również przypisywane do właściciela.

Podatność w interfejsie API ClearPass Policy Manager może pozwolić nieuwierzytelnionemu zdalnemu atakującemu na obejście istniejących mechanizmów uwierzytelniania. Udana eksploatacja może umożliwić atakującemu uzyskanie poufnych informacji z zaatakowanego systemu.

Podatność polegająca na ujawnieniu poufnych informacji występuje w oprogramowaniu klienckim HPE Networking ClearPass Policy Manager. Udana eksploatacja może pozwolić atakującemu z lokalnym dostępem do systemu na uzyskanie poufnych informacji.

Podatność w interfejsie klienckim HPE Networking ClearPass Policy Manager może pozwolić nieuwierzytelnionemu zdalnemu atakującemu na przeprowadzenie ataku DOM-based cross-site scripting (XSS) przeciwko użytkownikowi tego interfejsu. Udana eksploatacja może pozwolić na wykonanie dowolnego kodu skryptowego w kontekście przeglądarki ofiary.

Podatność typu command injection w agencie OnGuard ClearPass Policy Manager może pozwolić uwierzytelnionemu zdalnemu atakującemu na wstrzyknięcie dowolnych poleceń. Udana eksploatacja może pozwolić na wykonanie poleceń z podwyższonymi uprawnieniami na zaatakowanym punkcie końcowym Windows.

Podatność polegająca na zapisie dowolnego pliku w agencie OnGuard ClearPass Policy Manager może pozwolić złośliwym użytkownikom na lokalnej instancji na podniesienie uprawnień, jeśli spełnione są pewne warunki niezależne od atakującego. Udana eksploatacja może pozwolić lokalnemu atakującemu na wykonanie dowolnego kodu z podwyższonymi uprawnieniami.

Podatność polegająca na lokalnej eskalacji uprawnień występuje w oprogramowaniu klienckim ClearPass. Udana eksploatacja może pozwolić użytkownikowi lokalnemu o niskich uprawnieniach na wykonanie poleceń z podwyższonymi uprawnieniami, jeśli spełnione są pewne warunki niezależne od atakującego.

Podatność typu denial of service występuje w agencie OnGuard HPE Networking ClearPass Policy Manager. Udana eksploatacja może pozwolić uwierzytelnionemu lokalnemu atakującemu na przerwanie normalnego działania usługi agenta.

Luka SQL injection w API ClearPass Policy Manager może pozwolić zdalnemu uwierzytelnionemu atakującemu z uprawnieniami administracyjnymi na przeprowadzenie ataków SQL injection przeciwko instancji ClearPass Policy Manager. Udana eksploatacja może pozwolić atakującemu na wykonanie dowolnych poleceń bazy danych.

Luki zdalnego wykonania kodu w interfejsie HPE Networking ClearPass Policy Manager mogą pozwolić uwierzytelnionemu zdalnemu atakującemu z wysokimi uprawnieniami na wykonanie dowolnego kodu. Udana eksploatacja może pozwolić atakującemu na wykonanie dowolnych poleceń w systemie operacyjnym.

Podatność typu path traversal w punkcie API ClearPass Policy Manager pozwala nieuwierzytelnionemu zdalnemu atakującemu wpływać na decyzje autoryzacyjne i uzyskać nieprzewidzianą rolę.

Podatność przepełnienia bufora w agencie OnGuard ClearPass Policy Manager pozwala uwierzytelnionemu użytkownikowi lokalnemu na wykonanie dowolnego kodu z podwyższonymi uprawnieniami lub zakłócenie dostępności usługi.