Katalog podatności CVE

FFmpeg przed commit 1cdeb3c zawiera podatność przepełnienia bufora sterty w pakieteryzatorze RTP dla VC-2/Dirac (libavformat/rtpenc_vc2hq.c), która pozwala atakującym na wywołanie uszkodzenia pamięci poprzez dostarczenie spreparowanej jednostki danych Dirac. Pakieteryzator kopiuje rozmiar jednostki danych lub fragmentu pochodzącego z wejścia do bufora o stałym rozmiarze bez sprawdzenia górnej granicy, co powoduje przepełnienie bufora sterty, gdy spreparowane wejście jest pakieteryzowane do wyjścia RTP.

FFmpeg przed commit 9d786e4 zawiera podatność przepełnienia bufora stosu w multiplekserze MPEG-PS (libavformat/mpegenc.c). Podczas multipleksowania wejścia z większą liczbą strumieni niż mieści się w buforze o stałym rozmiarze na stosie, bufor jest przepełniany. Spreparowane wejście z nadmierną liczbą strumieni wyzwala przepełnienie podczas multipleksowania MPEG-PS.

FFmpeg przed commit acf5d7c zawiera podatność przepełnienia bufora sterty w pisarzu pudełka hvcC. Podczas zapisywania rekordu konfiguracji HEVC z większą liczbą jednostek NAL danego typu niż pole licznika może reprezentować, licznik jednostek NAL przepełnia się, co powoduje przepełnienie bufora sterty. Spreparowany plik wejściowy HEVC wyzwala przepełnienie podczas multipleksowania.

Wazuh to darmowa platforma open source używana do zapobiegania, wykrywania i reagowania na zagrożenia. Od wersji 4.5.0 do 4.14.6 i 5.0.0-beta2, funkcja compare_wazuh_versions() w src/shared/version_op.c kopiuje kontrolowane przez atakującego pole V z rejestracji do 10-bajtowego bufora na stosie za pomocą strncpy(), ale nie kończy jawnie bufora. Funkcja jest osiągalna przed uwierzytelnieniem przez wazuh-authd na porcie TCP 1515, gdy włączone jest anonimowe uwierzytelnianie TLS. Ciąg wersji o długości co najmniej dziewięciu niezerowych bajtów może spowodować, że strchr() i strtok() będą czytać poza ver2 i mogą sprawić, że strtok() zapisze bajt zerowy do sąsiedniej pamięci stosu, umożliwiając zdalną odmowę usługi. Problem został naprawiony w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta2 zawiera podatność w funkcji AffectedItemsWazuhResult.merge() w framework/wazuh/core/results.py, która ufa polu sort_casting w odpowiedzi JSON od pracownika klastra. Podczas scalania odpowiedzi API, nazwy typów kontrolowane przez atakującego są rozwiązywane przez wbudowane funkcje Pythona bez listy dozwolonych. Zainfekowany pracownik może ustawić sort_casting na exec i umieścić kod Pythona w affected_items, co powoduje wykonanie kodu przez mastera jako root podczas scalania odpowiedzi z wielu węzłów. Problem został naprawiony w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh od wersji 4.9.0 do 4.10.4 oraz 4.14.6 zawiera podatność w punkcie końcowym PUT /security/users/{user_id} w api/api/controllers/security_controller.py, gdzie przekazywany jest request.get("user") zamiast request.context['token_info']['sub'] jako current_user. Funkcja remove_nones_to_dict() usuwa wynikową wartość None, więc ochrona kont zarezerwowanych w framework/wazuh/security.py nie może zweryfikować, kto wykonuje żądanie. Uwierzytelniony użytkownik z rolą users_admin może nadpisać hasło chronionych kont administratora o identyfikatorach do 99, w tym superużytkownika wazuh, i uzyskać pełną kontrolę administracyjną. Problem został naprawiony w wersjach 4.10.4 i 4.14.6.

Podatność w parserze XML Open Client Interface (OCI) w Cisco BroadWorks umożliwia nieuwierzytelnionemu, zdalnemu atakującemu odczyt wrażliwych informacji konfiguracyjnych. Problem wynika z nieprawidłowego parsowania wpisów XML z powodu domyślnego zezwolenia na rozwiązywanie encji zewnętrznych. Atakujący może wysłać spreparowaną wiadomość XML do usługi OCI-P, co pozwala na odczyt wrażliwych plików z systemu plików z uprawnieniami użytkownika Cisco BroadWorks.

Cisco Secure Workload zawiera wiele podatności związanych z zarządzaniem buforami, sklasyfikowanych jako CWE-119. Zostały one wykryte podczas wewnętrznego przeglądu bezpieczeństwa i zaadresowane w wydaniu wzmacniającym oprogramowanie.

Secure BootROM układu RK3588s SoC jest podatny na atak typu time-of-check to time-of-use podczas uruchamiania z zewnętrznych nośników (SPI NOR lub NAND, EMMC lub SD). Kod dwukrotnie odczytuje nagłówek modułu ładującego następnego etapu; pierwszy odczyt jest częściowy i zawiera tylko hashe modułów, drugi jest pełny z podpisem. Autentyczność modułów jest sprawdzana na podstawie częściowych danych z pierwszego odczytu, co pozwala atakującemu z fizycznym dostępem na modyfikację danych i wykonanie dowolnego kodu z najwyższymi uprawnieniami (EL3).

Grav API Plugin przed wersją 1.0.8 przechwytuje zadania administracyjne apiKeyGenerate i apiKeyRevoke w user/plugins/api/api.php i autoryzuje wywołującego tylko przez admin.login. Podstawowy użytkownik panelu może wybrać inne konto z trasy, utworzyć trwałe poświadczenie ApiKeyManager powiązane z tym celem i odziedziczyć uprawnienia API celu, w tym api.super lub administracyjny zapis, jeśli są obecne. Problem został naprawiony w wersji 1.0.8.

Grav Shortcode Core Plugin przed wersją 6.2.2 przekazuje składnię shortcode przez Security::detectXss() bez literału '<', a następnie ColorShortcode.php i powiązane handlery atrybutów łączą kontrolowany przez atakującego parametr z HTML bez kodowania. Konto z uprawnieniem admin.pages może zamknąć wygenerowany atrybut i dodać handler zdarzeń, tworząc trwały cross-site scripting, który wykonuje się dla odwiedzających lub administratorów przeglądających stronę. Problem został naprawiony w wersji 6.2.2.

Grav przed wersją 2.0.7 zawiera podatność w Blueprint::dynamicData() w system/src/Grav/Common/Data/Blueprint.php, która przekazuje kontrolowany przez edytora dostawcę Class::method i argumenty do call_user_func_array() bez odrzucania niebezpiecznych parametrów wywołania zwrotnego. Konto z uprawnieniem admin.pages lub api.pages.write może użyć Grav\Common\Utils::arrayFilterRecursive() jako trampoliny z system jako wywołaniem zwrotnym, umieścić polecenie we frontmatter strony i wykonać je jako użytkownik serwera WWW podczas przeglądania strony. Problem został naprawiony w wersji 2.0.7.

Grav API Plugin przed wersją 1.0.0-rc.16 akceptuje JWT z parametru token w URL na każdej trasie /api/v1, w tym na punktach końcowych zmieniających stan. Żądania URL narażają ważne tokeny dostępu na logi Apache, proxy i CDN, historię przeglądarki i nagłówki Referer, co pozwala osobie z dostępem do tych rekordów na ponowne użycie tokena z uprawnieniami właściciela. Problem został naprawiony w wersji 1.0.0-rc.16.

Grav API Plugin przed wersją 1.0.0-rc.16 w CorsMiddleware zwraca Access-Control-Allow-Origin: * i permisywne odpowiedzi OPTIONS dla uwierzytelnionych punktów końcowych /api/v1. JavaScript z dowolnego pochodzenia może przesłać JWT uzyskany przez atakującego przez nagłówek Authorization lub X-API-Token, odczytać uwierzytelnioną odpowiedź i wykonać operacje zapisu z uprawnieniami właściciela tokena, umożliwiając eksfiltrację danych i modyfikację konta. Problem został naprawiony w wersji 1.0.0-rc.16.

Grav przed wersją 2.0.4 zawiera reguły bezpieczeństwa .htaccess, które porównują wzorce katalogów i rozszerzeń plików w sposób rozróżniający wielkość liter, bez flagi [NC]. Na systemach plików nie rozróżniających wielkości liter, nieuwierzytelniony atakujący może użyć wielkich liter, aby ominąć reguły i pobrać pliki z katalogów user/accounts lub user/config, w tym hasze haseł i konfigurację bezpieczeństwa. Problem naprawiono w wersji 2.0.4.

Wtyczka Grav Login przed wersją 3.8.11 zawiera podatność w zadaniu login.regenerate2FASecret, które sprawdza tylko istnienie użytkownika w sesji oczekującej, a nie wymaga autoryzacji $user->authorized. Po podaniu poprawnego hasła ofiary, atakujący może wywołać taskRegenerate2FASecret() podczas oczekującego wyzwania TOTP, nadpisać twofa_secret, odczytać nowy sekret z odpowiedzi, obliczyć ważny kod i ukończyć uwierzytelnianie bez drugiego czynnika ofiary. Problem naprawiono w wersji 3.8.11.

Wtyczka Grav API przed wersją 1.0.6 zawiera podatność, w której ApiKeyManager::generateKey() przechowuje zadeklarowaną tablicę zakresów, ale ApiKeyAuthenticator::authenticate() nie odczytuje keyData[scopes] i zwraca pełną tożsamość właściciela klucza. W rezultacie AbstractApiController::requirePermission() ocenia pełne ACL użytkownika, więc klucz wydany dla zakresu tylko do odczytu może wykonywać wszystkie operacje zapisu, usuwania i administracyjne dostępne właścicielowi. Problem naprawiono w wersji 1.0.6.

Wtyczka Grav API przed wersją 1.0.6 zawiera podatność, w której metody UsersController::createApiKey(), generate2fa() i disable2fa() pomijają sprawdzenie celu accessGrantsSuper() używanego w innych endpointach mutacji użytkownika. Konto niebędące superadministratorem z uprawnieniem api.users.write może utworzyć klucz API powiązany z celem access.api.super, uzyskać pełne uprawnienia celu, ponieważ zakresy kluczy nie są egzekwowane, i stworzyć trwały dostęp superadministratora; brakujące sprawdzenie umożliwia również rotację lub wyłączenie uwierzytelniania dwuskładnikowego celu. Problem naprawiono w wersji 1.0.6.

Wazuh od wersji 4.0.0 do 4.14.6 oraz 5.0.0-beta2 zawiera podatność w funkcji WazuhCommon.end_receiving_file() w framework/wazuh/core/cluster/common.py, która pozwala uwierzytelnionemu węzłowi klastra na usuwanie plików poza ścieżką WAZUH_PATH. Żądanie syn_i_w_m_e z nieznanym task_id dociera do gałęzi czyszczącej, gdzie nazwa pliku kontrolowana przez atakującego jest przekazywana do os.path.join bez kanonizacji lub ograniczeń. Ścieżki bezwzględne i sekwencje traversal mogą celować w pliki takie jak ossec.conf, jwt_secret.json, certyfikaty TLS i pliki reguł, które są dostępne dla procesu menedżera Wazuh. Usunięcie może wyłączyć menedżera, unieważnić tokeny API lub zakłócić łączność klastra i API. Problem naprawiono w wersjach 4.14.6 i 5.0.0-beta2.

Wazuh Manager od wersji 4.0.0 do 4.14.5 pozwala użytkownikowi API o niskich uprawnieniach (tylko do odczytu) z uprawnieniem manager:read na pobranie klucza klastra z elementu w ossec.conf przez GET /manager/configuration?raw=true. Atakujący z dostępem sieciowym do portu TCP 1516 może użyć ujawnionego klucza Fernet do podszycia się pod pracownika klastra i wysyłać rozproszone żądania API z kontrolowanymi rbac_permissions i rbac_mode ustawionym na black. Ponieważ master ufa kontekstowi autoryzacji dostarczonemu przez pracownika, atakujący może tworzyć użytkowników, przypisywać role administratora, uzyskiwać dostęp do poświadczeń i tokenów API, modyfikować konfigurację i wykonywać akcje na agentach. Problem naprawiono w wersji 4.14.5.