Katalog podatności CVE

MongoDB C++ Driver odrzuca zawartość po wbudowanym bajcie NUL w niektórych nazwach pól i kolekcji akceptowanych przez API kolekcji. To może spowodować, że sterownik i aplikacja będą interpretować tę samą nazwę różnie. Uwierzytelniony atakujący, który może wpłynąć na nazwę przekazaną przez aplikację, może spowodować, że aplikacja odczyta różne wartości z niezamierzonego pola lub zmieni nazwę niezamierzonej kolekcji.

Podatność w MongoDB libmongocrypt powoduje niedomiar liczby całkowitej w logice analizy punktów końcowych KMS, co może prowadzić do błędu alokacji i zakończenia procesu aplikacji. Problem występuje, gdy uwierzytelniony użytkownik modyfikuje dokument klucza w kolekcji key vault lub gdy aplikacja akceptuje punkt końcowy KMS zawierający dwukropek po ścieżce lub zapytaniu podczas tworzenia klucza. Podatność nie uzyskuje dostępu do pamięci poza przydzielonymi granicami.

Docker Sandboxes porównywały nazwy hostów punktów końcowych tokenów OAuth w sposób uwzględniający wielkość liter przy decydowaniu, czy maskować odpowiedzi zarządzanych poświadczeń, podczas gdy routing żądań traktował nazwy DNS bez uwzględniania wielkości liter. Niezaufany kod w sandboxie mógł użyć nazwy hosta z różną wielkością liter, aby dotrzeć do prawdziwego punktu końcowego dostawcy, omijając maskowanie odpowiedzi. Jeśli użytkownik ukończył przepływ OAuth, tokeny dostępu i odświeżania dostawcy mogły zostać zwrócone bez maskowania do sandboxa, ujawniając poświadczenia zarządzane przez hosta.

Docker Sandboxes mogły przekazywać poświadczenia dostarczone przez klienta wraz z poświadczeniem wstrzykniętym przez hosta przez proxy egress. Proxy usuwało alternatywne poświadczenia tylko wtedy, gdy ich wartości pasowały do znanych wartości sentinel, więc niezaufany kod w autoryzowanym sandboxie mógł dostarczyć nierozpoznane poświadczenie w innym obsługiwanym nagłówku autoryzacji. Dla dotkniętych usług zewnętrznych mogło to uwierzytelnić żądanie na koncie kontrolowanym przez atakującego i ujawnić dane zawarte w żądaniu.

Docker Sandboxes mogły zawieść w trybie otwartym podczas maskowania poświadczeń w chronionych odpowiedziach proxy. Gdy odczyt treści odpowiedzi zwracał dane wraz z błędem, dotknięte procedury mogły przekazywać niezmaskowane bajty. Kod wewnątrz autoryzowanego sandboxa mógł to wykorzystać do odzyskania zarządzanych przez hosta tokenów OAuth dostępu i odświeżania lub pochodnego klucza API Anthropic, który miał pozostać poza sandboxem.

GnuTLS w wersji 3.8.13 nie odrzuca krytycznego rozszerzenia keyUsage, gdy nie może go przetworzyć, np. gdy extnValue jest typu ASN.1 NULL (05 00) zamiast BIT STRING. Dostawca nie uznaje tego za realną podatność bezpieczeństwa ze względu na swój model zagrożeń, który nie uwzględnia ataków wymagających modyfikacji elementów w granicach zaufania.

GnuTLS v3.8.13 nie egzekwuje prawidłowo ograniczeń nazw (name constraints), co pokazano na przykładzie naruszenia dozwolonego poddrzewa ("EE O=Evil accepted although outside permitted O=Good"). Dostawca nie uznaje tego za podatność bezpieczeństwa z powodu przyjętego modelu zagrożeń.

W OpenStack Mistral do wersji 23.0.0, API członkostwa przepływów pracy pozwala projektowi, który zaakceptował udział w prywatnym przepływie pracy innego projektu, na utworzenie kolejnego członkostwa wskazującego trzeci projekt. Nowy wiersz członkostwa jest tworzony z project_id ustawionym na projekt akceptujący, a nie na pierwotnego właściciela przepływu, więc właściciel nie może go zobaczyć ani usunąć. Trzeci projekt może zaakceptować to członkostwo (które nie zostało faktycznie przyznane przez właściciela), a następnie czytać i wykonywać prywatny przepływ pracy właściciela; tylko projekt akceptujący (nie właściciel) może później cofnąć ten dostęp.

QloApps do wersji 1.7.0 zawiera podatność na obejście autoryzacji w AdminHotelRoomsBookingController::postProcess(), która pozwala ograniczonym pracownikom back-office na dostęp do danych innych hoteli poprzez podanie parametru id_hotel. Atakujący mogą zmodyfikować parametr id_hotel w URL na stronie Book Now, aby zobaczyć dostępność pokoi i status rezerwacji hoteli spoza ich przypisanego profilu dostępu.

FFmpeg przed wersją 7.1.4 i 8.0.x przed 8.0.2 zawiera podatność na atak SSRF w ff_rtsp_connect() w libavformat/rtsp.c, która podąża za przekierowaniami RTSP 3xx bez walidacji URL Location. Złośliwe serwery RTSP mogą przekierować FFmpeg do wewnętrznych hostów i portów w innych schematach, omijając -protocol_whitelist, w celu sondowania wewnętrznych usług sieciowych.

FFmpeg przed wersją 8.1.3 zawiera błąd mechanizmu ochrony w demuxerze HLS, który pozwala atakującym ominąć ograniczenia protokołów i dozwolonych rozszerzeń podczas otwierania podrzędnych playlist. Atakujący mogą dostarczyć spreparowaną playlistę główną, której podrzędne playlisty używają niedozwolonych protokołów lub lokalnych plików niebędących multimediami, co powoduje, że parse_playlist() otwiera zasoby, które polityka bezpieczeństwa HLS powinna blokować.

FFmpeg do wersji 9.0.2 zawiera podatność na nieskończoną pętlę w ff_rtsp_connect() w libavformat/rtsp.c, która podąża za przekierowaniami RTSP 3xx bez żadnego limitu przekierowań. Atakujący kontrolujący serwer RTSP mogą odpowiadać na każde żądanie przekierowaniem 302 do siebie lub innego serwera, powodując niekończące się ponowne połączenia, które przeciążają rdzeń procesora.

FFmpeg przed wersją 8.1.3 zawiera podatność na nieskończoną pętlę w demuxerze HLS, która pozwala zdalnym atakującym spowodować denial of service, ponieważ parse_playlist() akceptuje tagi Master Playlist wewnątrz Media Playlists. Atakujący mogą nakłonić ofiary do otwarcia spreparowanej samoodnoszącej się playlisty, która nieskończenie dodaje warianty w hls_read_header(), powodując nieograniczone zużycie CPU i I/O.

savg-sanitizer to PHP sanitizer SVG/XML. Przed wersją 1.0.0 funkcja isHrefSafeValue() sprawdza atrybut href po ekspansji encji DTD, ale saveXML() serializuje oryginalną encję po usunięciu deklaracji DTD. Specjalnie spreparowana encja, np. Tab, może wyglądać dla sanitizera jak bezpieczny fragment prefiksu, podczas gdy HTML5 Named Character Reference podczas renderowania inline zamienia przetrwałą encję na biały znak, odsłaniając URL javascript:. Gdy aplikacja osadza oczyszczony SVG inline, użytkownik aktywujący link może spowodować wykonanie skryptu w kontekście strony osadzającej. Problem naprawiono w wersji 1.0.0.

savg-sanitizer to PHP sanitizer SVG/XML. Przed wersją 1.0.0, spreparowany DTD SVG z atrybutem #FIXED może spowodować, że cleanAttributesOnWhitelist() wykona podwójne wywołanie DOMElement::removeAttribute() na tej samej nazwie atrybutu w src/Sanitizer.php. Pierwsze usunięcie usuwa jawny atrybut, a domyślna wartość DTD rematerializuje wartość przed drugim usunięciem w ścieżce bezpieczeństwa href, co może uszkodzić stan libxml i zakończyć proces PHP. Atakujący, który może przesłać zawartość SVG do punktu sanityzacji, może wielokrotnie przerywać pracę workerów i degradować lub wyczerpać dostępność aplikacji. Problem naprawiono w wersji 1.0.0.

Usługa Arkime live capture (arkime-live) w Malcolm działa z network_mode: host, wystawiając port 8005 na wszystkich interfejsach sieciowych (viewHost=0.0.0.0). Arkime ufa nagłówkowi X-Forwarded-User z dowolnego adresu IP (userAuthIps=::,0.0.0.0/0) i automatycznie tworzy użytkowników z pełnym dostępem. passwordSecret jest zaszyty na stałe do publicznej wartości "Malcolm". Atakujący w sieci może ominąć nginx całkowicie, łącząc się bezpośrednio z portem 8005 z podrobionym nagłówkiem tożsamości.

Frontowy reverse proxy nginx w Malcolm definiuje lokalizację "Dashboards → Arkime shortcut" używając matchera regex bez rozróżniania wielkości liter, ale przepisania (rewrite) z rozróżnianiem wielkości liter. Żądanie, którego segment ścieżki nie jest dokładnie małymi literami (np. /IDDASH2ARK/...) wchodzi do lokalizacji (matcher działa), ale omija przepisanie (brak przekierowania), więc nginx przechodzi do proxy_pass lokalizacji do backendu Arkime. Ta lokalizacja jest jedyną proxowaną lokalizacją w dostarczonej konfiguracji, która nie zawiera pliku uwierzytelniania per lokalizacja, więc żądanie dociera do Arkime bez uwierzytelnienia. Ta sama lokalizacja przekazuje również nagłówek X-Forwarded-User dostarczony przez klienta bez nadpisania, a Arkime jest skonfigurowany, aby ufać X-Forwarded-User jako nazwie uwierzytelnionego użytkownika — więc nieuwierzytelniony wywołujący z sieci może dotrzeć do backendu Arkime, podając podrobioną, automatycznie utworzoną tożsamość.

Potok przetwarzania uploadów w Malcolm (scripts/safe-extract.py) egzekwuje limity liczby wpisów, głębokości zagnieżdżenia i całkowitego rozmiaru nieskompresowanego podczas rozpakowywania archiwów kontenerowych (zip/tar/rar/7z przez libarchive), ale te limity nie są stosowane, gdy przesłany plik jest pojedynczym strumieniem skompresowanym (.gz, .bz2, .xz, .lzma, .lz), który nie jest archiwum .tar.*. Każdy uwierzytelniony użytkownik uprawniony do przesyłania plików PCAP/log może przesłać mały, wysoko kompresowalny plik (np. bombę gzip), który dekompresuje się do praktycznie nieograniczonego rozmiaru na dysku, wyczerpując współdzielony wolumen Docker używany przez OpenSearch, Logstash, Arkime i Zeek, i zakłócając platformę dla wszystkich użytkowników.

Warstwa kontroli dostępu oparta na rolach (RBAC) nginx Lua w Malcolm decyduje, czy uwierzytelniony użytkownik może uzyskać dostęp do ścieżki ograniczonej rolą (np. /htadmin, /auth, /admin_login, /arkime/api/esadmin, NetBox, punkty uploadu) przez dopasowanie wzorca do surowego, percent-encoded URI żądania. Sam nginx wybiera jednak, która lokalizacja faktycznie obsługuje żądanie, używając zdekodowanego, znormalizowanego URI. Ponieważ kontrola RBAC nigdy nie dekoduje percent-encoding, uwierzytelniony użytkownik z niskimi uprawnieniami może zażądać ścieżki admin-only używając percent-encoding (np. /%68tadmin.php) i nginx przekieruje go do ograniczonej lokalizacji, podczas gdy brama Lua RBAC oceniająca nieodkodowany surowy string nie znajdzie żadnego ograniczenia i przyzna dostęp.

Niebezpieczne uprawnienia do plików w handlerze połączeń CodeCatalyst w AWS Toolkit for VS Code przed wersją 4.10.0 pozwalały lokalnym użytkownikom uzyskać tokeny CodeCatalyst poprzez odczyt plików cache tokenów, które były czytelne dla wszystkich. Aby złagodzić ten problem, użytkownicy powinni zaktualizować do wersji 4.10.0 lub nowszej.