Katalog podatności CVE

W Gitea tablice projektów repozytoriów i organizacji wyświetlały pull requesty odwołujące się do każdego zgłoszenia na tablicy bez sprawdzania, czy widz może je odczytać. Gdy prywatny pull request wspominał zgłoszenie na tablicy, którą widz może otworzyć, tablica ujawniała ścieżkę prywatnego repozytorium oraz numer, tytuł i stan pull requesta, w przypadku publicznej tablicy także anonimowym odwiedzającym. Treść, diff i pliki pull requesta nie zostały ujawnione.

W Gitea trasa DELETE /api/v1/orgs/{org}/repos usuwa wszystkie repozytoria organizacji, ale nie egzekwowała ograniczenia public-only tokenów dostępu: sprawdzała jedynie, czy sama organizacja jest publiczna. Token public-only właściciela publicznej organizacji mógł zatem trwale usunąć prywatne repozytoria organizacji, do których taki token nie powinien mieć dostępu.

W Gitea interfejs webowy blokuje zmiany zgłoszeń i pull requestów w zarchiwizowanych repozytoriach, ale kilka tras zgłoszeń w REST API nie sprawdzało, czy repozytorium jest zarchiwizowane. Użytkownik uprawniony do zmiany zgłoszeń w zarchiwizowanym repozytorium mógł przez API edytować, zamykać lub usuwać zgłoszenia, zmieniać etykiety i terminy, dodawać lub usuwać śledzony czas i stopery, dodawać reakcje, zmieniać blokady zgłoszeń i przypinać zgłoszenia, modyfikując dane, które archiwizacja ma zamrozić.

W Gitea wersja 1.27.3 uniemożliwiła osobistym tokenom dostępu ograniczonym do zasobów publicznych (public-only) tworzenie repozytoriów przez POST /api/v1/user/repos i POST /api/v1/repos/migrate, ale trasy POST /api/v1/org/{org}/repos, POST /api/v1/orgs/{org}/repos, POST /api/v1/orgs i POST /api/v1/repos/{owner}/{repo}/generate nadal akceptowały takie tokeny. Posiadacz tokena public-only z potrzebnymi zakresami zapisu mógł tworzyć prywatne repozytoria w organizacjach, w których właściciel tokena może tworzyć repozytoria, tworzyć prywatne organizacje i generować prywatne repozytoria z szablonów.

W Gitea endpoint userinfo OAuth2 (/login/oauth/userinfo) decydował, czy ograniczyć roszczenie groups do publicznych organizacji, ponownie parsując nagłówek Authorization jako token dostępu OAuth2, zamiast używać zakresu poświadczenia, które uwierzytelniło żądanie. Gdy token OAuth2 public-only był przesyłany jako parametr zapytania lub pole formularza, albo używano osobistego tokena public-only, zakres wracał pusty, a roszczenie wymieniało prywatne organizacje, zespoły i ukryte członkostwa właściciela tokena.

W Gitea workflowy wyzwalane przez recenzję pull requesta były odczytywane z commita wskazanego w commit_id recenzji, podczas gdy ograniczenia fork były ustalane na podstawie recenzowanego pull requesta, a commit nie był sprawdzany pod kątem przynależności do tego pull requesta. Użytkownik z dostępem do odczytu repozytorium mógł umieścić w nim własny commit, przez pull request z forka lub push AGit, i przesłać recenzję wskazującą ten commit na pull requeście, którego gałąź head znajduje się w tym samym repozytorium. Na instancjach z runnerem obsługującym repozytorium workflow atakującego uruchamiał się bez zatwierdzenia, otrzymywał sekrety Actions repozytorium i jego właściciela oraz GITEA_TOKEN z dostępem zapisu do repozytorium.

W rejestrze OCI mechanizm montowania blobów między repozytoriami sprawdzał docelowy pakiet względem ograniczenia tokenu `public-only`, ale źródłowy blob weryfikował tylko względem pełnych uprawnień właściciela tokenu. Token `public-only` z zakresem `write:package`, którego właściciel może czytać prywatny pakiet i pisać do publicznej przestrzeni nazw, mógł zamontować blob prywatnego pakietu w publicznym pakiecie, a następnie każdy mógł go pobrać.

Podczas parsowania przesłanego wykresu Helm Gitea dekompresowała archiwum i odczytywała każdy wpis tar w poszukiwaniu `Chart.yaml` bez limitu rozmiaru po dekompresji, a robiła to przed sprawdzeniem limitu rozmiaru pakietu, który uwzględnia tylko skompresowany rozmiar przesłania. Użytkownik z prawem zapisu do pakietów mógł wielokrotnie przesyłać małe, silnie skompresowane archiwa, powodując zużycie CPU proporcjonalne do rozmiaru po dekompresji i pogorszenie dostępności instancji Gitea.

API osi czasu zgłoszeń oraz strona WWW zgłoszenia ukrywały zdarzenia odwołań krzyżowych wskazujące na zgłoszenia niedostępne dla czytelnika, ale nie ukrywały zdarzeń „dependency added” i „dependency removed”. Gdy czytelne zgłoszenie było powiązane jako zależność ze zgłoszeniem w niedostępnym repozytorium, każdy czytelnik pierwszego zgłoszenia, w tym anonimowi użytkownicy publicznego repozytorium, otrzymywał tytuł, treść, stan, etykiety, autora i nazwy załączników powiązanego zgłoszenia przez API oraz jego repozytorium, numer i tytuł na stronie WWW.

Zakładki repozytoriów, gwiazdek i obserwowanych w profilach użytkowników oraz lista repozytoriów na stronach głównych organizacji zawierały prywatne repozytoria dla każdego zalogowanego żądania bez sprawdzania, czy żądanie używa tokenu dostępu ograniczonego do zasobów publicznych (`public-only`). Posiadacz takiego tokenu mógł wylistować prywatne repozytoria widoczne dla właściciela tokenu oraz jego gwiazdki i obserwacje prywatnych repozytoriów.

Grupa tras `/api/v1/admin` nie egzekwowała ograniczenia `public-only` tokenów dostępu osobistego. Token public-only z zakresem administratora wydany przez administratora witryny mógł wylistować prywatne organizacje i adresy e-mail wszystkich użytkowników, tworzyć organizacje, uzyskiwać tokeny rejestracji runnerów oraz tworzyć nowe konta administratorów witryny, które pozostają aktywne po unieważnieniu tokenu.

Token `GITEA_TOKEN` zadania Gitea Actions uwierzytelnia jako użytkownik systemowy `gitea-actions`, a endpointy e-mail i kluczy GPG `/api/v1/user` akceptowały tego użytkownika, więc zadanie mogło zarejestrować adres e-mail i klucz GPG; bez wymaganego potwierdzenia e-mail adres był zapisywany jako aktywowany. Weryfikacja commitów traktuje klucz bez rzeczywistego właściciela jako klucz podpisujący instancji, więc każdy użytkownik mogący uruchomić zadanie workflow mógł sprawić, że commity podpisane jego własnym kluczem były wyświetlane jako zaufane i podpisane przez instancję.

Trasy API dla wydań, zasobów wydań, kamieni milowych i etykiet repozytorium nie odrzucały zmian w zarchiwizowanych repozytoriach. Użytkownik z prawem zapisu do zarchiwizowanego repozytorium lub posiadacz jego tokenu z zakresem zapisu mógł zastępować lub usuwać zasoby wydań zachowując ich adresy pobierania, usuwać wydania i tagi oraz tworzyć, edytować lub usuwać kamienie milowe i etykiety repozytorium, które powinno być tylko do odczytu.

Gitea nie odrzucała tokenów dostępu osobistego ograniczonych do zasobów publicznych (`public-only`) na endpoincie tokenu rejestracji runnera Actions organizacji, a runner zarejestrowany uzyskanym tokenem nie był ograniczony do publicznych repozytoriów. Posiadając tylko taki token z `write:organization` należący do właściciela publicznej organizacji, atakujący mógł zarejestrować runner na poziomie organizacji i odbierać zadania prywatnych repozytoriów organizacji z włączonym Actions, w tym treść workflow, sekrety i zmienne Actions oraz token zadania z dostępem do prywatnego repozytorium.

Endpoint `GET /api/v1/users/{username}/heatmap` obliczał mapę cieplną wkładu z uprawnieniami dostępu do repozytoriów właściciela tokenu i ignorował ograniczenie `public-only` tokenu dostępu, w przeciwieństwie do endpointów aktywności. Posiadacz tokenu public-only użytkownika mógł odczytać liczby wkładu i ich 15-minutowe przedziały czasowe pochodzące z aktywności tego użytkownika w prywatnych repozytoriach.

Starsze (v1 do v3) przesyłanie artefaktów Actions przechowywało nagłówek `Content-Encoding` żądania bez sprawdzenia w kolumnie serwowanej jako `Content-Type` artefaktu przy pobieraniu, a wartość zaczynająca się od `video/` lub `audio/` usuwała także politykę Content-Security-Policy piaskownicy. Użytkownik mogący uruchomić zadanie Actions mógł przesłać artefakt renderowany przez przeglądarkę jako HTML w domenie Gitea po otwarciu bezpośredniego adresu pobierania, a adres jest anonimowo osiągalny w publicznych repozytoriach.

Podatność w Gitea Actions polega na tym, że tokeny zadań uwierzytelniają się w API REST jako wspólny użytkownik systemowy o ujemnym ID, który nie podlega ograniczeniom właścicielskim w filtrach repozytoriów, organizacji, projektów i kluczy. Token nie miał też zakresu API ograniczającego trasy użytkownika, więc użytkownik mogący uruchomić workflow mógł użyć tokenu z `GET /api/v1/user/repos`, aby wylistować wszystkie repozytoria w instancji, w tym prywatne repozytoria innych użytkowników i organizacji, wraz z metadanymi. Zawartość repozytoriów pozostawała chroniona przez kontrolę uprawnień na poziomie repozytorium.

W systemie Typemill do wersji 2.26.0 wykryto podatność w funkcji ControllerApiImage::saveImage w pliku system/typemill/Models/SvgSanitizer.php. Manipulacja danymi może prowadzić do cross-site scripting (XSS), a atak można przeprowadzić zdalnie. Exploit został opublikowany i może być wykorzystany; aktualizacja do wersji 2.27.0 (patch 9ca43c4a7b6764c5a6ac11a2ccc099b036ee3cef) rozwiązuje problem.

W bibliotece loguru w wersji 0.7.3 wykryto podatność w funkcji AnsiParser.feed w pliku loguru/_colorizer.py, odpowiedzialnej za parsowanie kolorów ANSI. Manipulacja danymi wejściowymi prowadzi do nieefektywnej złożoności wyrażeń regularnych (ReDoS), a atak można przeprowadzić zdalnie. Exploit jest publicznie dostępny, a producent nie odpowiedział na zgłoszenie.

W urządzeniu WAVLINK WL-WN530BE1-A (wersja V251117) wykryto podatność w funkcji con_check_read_finish w pliku /protocol.csp. Manipulacja argumentem group_name/IP-FROM prowadzi do wstrzyknięcia poleceń. Atak można przeprowadzić zdalnie, a exploit został publicznie ujawniony.