Katalog podatności CVE

Beta9 zamienia każdą komendę powłoki w definicji obrazu dzierżawcy na linię RUN w Dockerfile i wykonuje ją za pomocą Buildah na workerze budowania. Obraz workera ustawia BUILDAH_ISOLATION=chroot, a żadne wywołanie buildah nie przekazuje --isolation, więc krok zmienia tylko katalog główny systemu plików, zachowując przestrzenie nazw PID, sieci, IPC i użytkownika workera, działając jako uid 0 z CAP_DAC_OVERRIDE. PID 1 w tym procfs to entrypoint workera, więc /proc/1/root to system plików kontenera workera i jest zapisywalny, zawierając binaria runc, buildah i runsc, token konta usługi Kubernetes oraz katalogi hosta zamontowane w podzie. Pody workera są uprzywilejowane, a warstwowe budowy Clip v2 są domyślne, więc dzierżawca z tokenem workspace może to osiągnąć, przesyłając jedną budowę obrazu.

W WAVLINK WN701AE M01AE_V260105 wykryto podatność w funkcji del_staticrule pliku static_route_setting.sh komponentu ioos Web Backend. Manipulacja argumentem rule_name prowadzi do wstrzyknięcia poleceń systemu operacyjnego. Zdalne wykorzystanie podatności jest możliwe, a exploit jest publicznie dostępny i może być użyty.

Wykryto podatność przepełnienia bufora w bibliotece P2PAPI.dll 1.3.3.32 firmy Hangzhou Xiongmai Technology na systemie Windows. Luka dotyczy funkcji P2PAPI_Connect w komponencie P2P SDK i jest wywoływana przez manipulację argumentem wejściowym typu String. Atak wymaga dostępu lokalnego, a exploit został publicznie ujawniony i może być wykorzystany.

W modułach Perl HTTP::Session w wersjach przed 0.54 identyfikator sesji z ciasteczka klienta trafia bez filtrowania do magazynu CHI, co umożliwia wstrzyknięcie poleceń do memcached. Znaki CR i LF w identyfikatorze sesji kończą polecenie cache i pozwalają serwerowi odczytać kolejne bajty jako dodatkowe polecenia.

W urządzeniu Oray Pugongying X5 Pro do wersji 7.6.1 funkcja config_restore_ex w pliku /etc/openwrt_release jest podatna na przejście ścieżki względnej poprzez manipulację argumentem filename. Atak można zainicjować zdalnie, a publiczny exploit jest już dostępny.

W urządzeniu Oray Pugongying X5 Pro do wersji 7.6.1 funkcje run_apis_by_json/run_async_task w komponencie API Authorization pozwalają na obejście kontroli autoryzacji. Atak można przeprowadzić zdalnie, a publiczny exploit został udostępniony.

Gdy w Gitea opcja [oauth2_client].ACCOUNT_LINKING jest ustawiona na auto (nie domyślnie) i rejestracja jest włączona, formularz rejestracji przez linkowanie konta wyszukiwał istniejące konto po nazwie użytkownika lub e-mailu z formularza, zamiast po tożsamości potwierdzonej przez dostawcę OAuth2. Atakujący z kontem u dostawcy OAuth2 mógł podać nazwę innego użytkownika, powiązać swoją tożsamość zewnętrzną z tym kontem Gitea i zalogować się jako on bez hasła, w tym jako administrator; powiązanie pozostawało aktywne przy kolejnych logowaniach.

W produkcie Oray Pugongying X5 Pro do wersji 7.6.1 funkcja session_get w pliku session.lua (komponent obsługi identyfikatorów sesji) generuje niewystarczająco losowe wartości na podstawie argumentu _user. Atak można przeprowadzić zdalnie, choć jego złożoność ocenia się jako wysoką, a wykorzystanie jako trudne. Exploit jest publicznie dostępny, a producent nie odpowiedział na zgłoszenie.

W Gitea trasy webowego profilu oraz kanałów RSS/Atom użytkowników i organizacji sprawdzały jedynie, czy zalogowany widz może zobaczyć właściciela o ograniczonej widoczności, nie uwzględniając ograniczenia public-only tokena dostępu użytego do uwierzytelnienia. Każdy użytkownik z tokenem public-only mógł przesłać go przez HTTP Basic authentication i odczytać profil oraz kanał aktywności użytkowników i organizacji o ograniczonej widoczności, ukrytych przed anonimowymi odwiedzającymi i odrzucanych na równoważnych trasach API.

W Gitea trasa webowa /{username} akceptowała osobiste tokeny dostępu przez HTTP Basic authentication bez sprawdzania ich zakresu. Token ograniczony do niepowiązanego zakresu, np. read:issue, mógł odczytać prywatną aktywność właściciela przez kanał RSS/Atom i kartę aktywności profilu oraz aktywność innych członków prywatnej organizacji przez kanał organizacji; token public-only mógł wylistować prywatne repozytoria i organizacje właściciela oraz wyrenderować prywatne README profilu. Dla tokena administratora serwisu dotyczyło to każdego konta.

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.