Katalog podatności CVE

FreeRDP w wersjach od 3.3.0 przed 3.32.0, zbudowany z opcją WINPR_UTILS_IMAGE_JPEG=ON, ma zapis poza zakresem bufora sterty w funkcji winpr_convert_from_jpeg, ponieważ bufory dla obrazów JPEG w skali szarości są rozmiarowane na podstawie jednego składnika wejściowego zamiast trzech składników wyjściowych BGR. Złośliwy serwer RDP może zaoferować obraz JPEG w skali szarości przez przekierowanie schowka, uszkadzając pamięć klienta i powodując jego awarię przy wklejaniu elementu jako danych bitmapowych CF_DIB.

Serwer shadow FreeRDP od wersji 3.0.0 przed 3.32.0 wysyła pakiety PDU wejścia w stanie Confirm Active przed uwierzytelnieniem, co pozwala nieuwierzytelnionym atakującym wstrzykiwać dane wejściowe z klawiatury. Atakujący może wynegocjować RDP tylko z TLS i wysłać pakiet PDU wejścia bez Confirm Active, aby wstrzyknąć syntetyczne naciśnięcia klawiszy do sesji X11 użytkownika hosta przez XTEST.

FreeRDP od wersji 2.0.0 przed 3.32.0, zbudowany z opcjami WITH_LAME=ON i WITH_DSP_FFMPEG=OFF, ma przepełnienie bufora sterty w funkcji freerdp_dsp_decode_mp3, ponieważ wskaźnik PCM prawego kanału jest przesunięty o liczbę bajtów traktowaną jako elementy typu short. Złośliwy serwer RDP może wysłać dźwięk MP3 przez rdpsnd, przez co zdekodowane próbki wykraczają poza alokację sterty, powodując awarię klienta.

Interfejsy API zarządzania certyfikatami i kluczami prywatnymi MSP oraz OpenAPI w Omada Controller nie egzekwują prawidłowo autoryzacji administracyjnej, co pozwala uwierzytelnionemu użytkownikowi wykonywać uprzywilejowane operacje zarządzania certyfikatami. Skuteczne wykorzystanie może pozwolić użytkownikowi z niskimi uprawnieniami na przesłanie lub usunięcie certyfikatu TLS lub klucza prywatnego kontrolera, potencjalnie zakłócając bezpieczny dostęp zarządzania.

Administrator mógł odzyskać kod resetowania hasła dowolnego użytkownika i przejąć jego konto. Kody resetowania hasła były zwracane w odpowiedzi API i mogły zostać użyte do zresetowania hasła dowolnego konta; API było ograniczone wyłącznie do kont administratorów. Atakujący posiadający już dostęp administracyjny do aplikacji mógł przejąć poświadczenia innych kont, choć poświadczenia urządzeń i dane klientów nie były dostępne przez tę podatność.

W trybie MSP Omada Controller punkt końcowy potwierdzenia użytkownika nie egzekwuje wymaganego sprawdzenia uprawnień. Uwierzytelniony użytkownik może podać kontrolowany przez siebie parametr Identifier, aby zweryfikować poświadczenia innego konta i otrzymać odpowiedzi rozróżniające nieistniejących użytkowników, nieprawidłowe hasła oraz udane uwierzytelnienie. Skuteczne wykorzystanie może umożliwić enumerację użytkowników, weryfikację poświadczeń i nieautoryzowany dostęp do zasobów MSP lub przejęcie kont docelowych.

W SonicWall Network Security Manager (NSM) on-prem wykryto podatność nieprawidłowej kontroli dostępu w ustawieniach eksportu. Uwierzytelniony zdalny atakujący może uzyskać dostęp do poufnych informacji, co może pozwolić na eskalację uprawnień do administratora lub przechwytywanie komunikacji innych użytkowników instancji NSM.

OpenAEV to platforma open source do planowania, harmonogramowania i przeprowadzania kampanii symulacji przeciwnika oraz testów. W wersjach przed 2.260622.0, przy domyślnej instalacji, punkty końcowe /api/player/** lessons mogą być wywoływane bez uwierzytelnienia i ufają parametrowi zapytania userId dostarczonemu przez klienta, nie weryfikując, czy wywołujący jest tym użytkownikiem lub członkiem ćwiczenia. Nieuwierzytelniony klient znający UUID ćwiczenia może odczytać pytania i odpowiedzi lessons-learned (w tym tożsamość autora każdej odpowiedzi) oraz tworzyć lub nadpisywać odpowiedzi przypisane dowolnemu użytkownikowi. Wersja 2.260622.0 zawiera poprawkę.

W FileRise przed wersją 3.18.0 ścieżki folderów są spłaszczane do nazw plików metadanych poprzez zastępowanie separatorów i spacji myślnikami, przez co różne foldery (np. team/docs i team-docs) mogą współdzielić jeden plik metadanych. Użytkownik o niskich uprawnieniach, który kontroluje kolidujący folder i zna nazwę pliku docelowego, może zmodyfikować metadane, sprawić że cudzy plik wygląda na jego własny, a następnie go odczytać i zmodyfikować.

W FileRise przed wersją 3.18.0 udostępnione foldery z możliwością wysyłania oraz linki tylko do wysyłania nie odrzucają nazwy pliku docelowego, która już istnieje. Nieuwierzytelniony gość z ważnym tokenem udostępniania i hasłem może wysłać plik o tej samej nazwie i po cichu zastąpić jego zawartość, zachowując oryginalne metadane. Ten sam problem dotyczy zwykłych uwierzytelnionych wysyłek przez /api/upload/upload.php oraz użytkowników tylko do wysyłania bez prawa edycji istniejącego pliku.

W FileRise przed wersją 3.16.0 pusty lub brakujący plik users.txt jest traktowany jako świeża instalacja, nawet jeśli konfiguracja została już wcześniej ukończona. Jeśli utrata danych, obcięcie lub inna awaria opróżni magazyn użytkowników, nieuwierzytelniony zdalny atakujący może wykryć ponowne otwarcie trybu konfiguracji i utworzyć kolejne konto administratora. Aplikacja nie miała trwałego znacznika ukończenia konfiguracji niezależnego od modyfikowalnego magazynu użytkowników.

W FileRise przed wersją 3.16.0, gdy administrator włączył WebDAV, uwierzytelnianie Basic w FileRise WebDAV sprawdza tylko nazwę użytkownika i hasło przez AuthModel::authenticate() i nie wymusza skonfigurowanego czynnika TOTP. Atakujący znający prawidłowe poświadczenia podstawowe konta z włączonym TOTP może uwierzytelnić się w usłudze WebDAV bez drugiego czynnika i korzystać z uprawnień plikowych konta. Ścieżka logowania w przeglądarce wymusza TOTP, ale osobne wywołanie zwrotne public/webdav.php tego nie robiło.

W FileRise przed wersją 3.16.0 wdrożenia z włączonym AUTH_BYPASS ufają skonfigurowanemu nagłówkowi tożsamości reverse-proxy bez weryfikacji, że żądanie pochodzi z FR_TRUSTED_PROXIES. Gdy port backendu jest osiągalny bezpośrednio, nieuwierzytelniony atakujący może podać X-Remote-User i uzyskać sesję dla wskazanego konta, w tym konta administratora, bez hasła i MFA. Wada dotyczy tylko wdrożeń z włączonym uwierzytelnianiem przez nagłówki proxy i wystawioną niezaufaną ścieżką do backendu.

W OpenSIPS do wersji 3.6.8/4.0.1 funkcja rtpproxy_offer/rtpproxy_answer komponentu rtpproxy zawiera podatność powodującą odczyt poza zakresem pamięci. Atak może być zainicjowany zdalnie. Aktualizacja do wersji 3.6.9 lub 4.0.2 rozwiązuje problem.

W narzędziu sar2html w wersji 4.0.0 wykryto podatność typu SQL injection w funkcji updateDb w pliku sar2html.py, w komponencie przetwarzania archiwów. Manipulacja argumentem s2host pozwala na wstrzyknięcie kodu SQL. Atak można przeprowadzić zdalnie.

W FileRise przed wersją 3.23.0 uwierzytelniona tożsamość OIDC jest mapowana na konto lokalne przy użyciu zmiennych roszczeń preferred_username lub email, bez wymogu email_verified. Atakujący mogący uzyskać od dostawcy roszczenie kolidujące z istniejącą nazwą użytkownika może zalogować się jako to konto, w tym jako wbudowany administrator, nawet gdy automatyczne tworzenie kont jest wyłączone.

W FileRise przed wersją 3.23.0 nieudane próby weryfikacji TOTP są przechowywane w $_SESSION, co pozwala atakującemu posiadającemu ważne podstawowe poświadczenia konta na restart procesu logowania w nowej sesji i przywrócenie limitu prób. Umożliwia to dalsze zgadywanie kodów TOTP poza zamierzonym limitem pięciu prób.

W SonicWall Network Security Manager (NSM) on-prem wykryto podatność typu OS Command Injection występującą po uwierzytelnieniu, wynikającą z nieprawidłowej neutralizacji specjalnych elementów w poleceniach systemu operacyjnego. W określonych warunkach uwierzytelniony zdalny atakujący może wykonać dowolne polecenia systemowe, co prowadzi do zdalnego wykonania kodu.

W WeGIA przed wersją 3.8.6 plik sessionStart.php odzwierciedla atakujący-supplied cookie PHPSESSID w odpowiedzi Set-Cookie i używa DB_HOST jako domeny cookie. Jeśli ofiara uwierzytelnia się używając identyfikatora wybranego przez atakującego, atakujący może go ponownie użyć do przejęcia sesji. Odpowiedź ujawnia również wewnętrzną nazwę hosta bazy danych.

W WeGIA przed wersją 3.8.6 uwierzytelniony użytkownik z dostępem do modułu Material & Patrimônio może przesłać id_produto do web/html/matPat/restaurar_produto_desocultar.php, gdzie drugie extract($_REQUEST) nadpisuje wartość wcześniej oczyszczoną przez intval(). Surowa wartość jest wstawiana do zapytań UPDATE dla tabel produto, isaida i ientrada, umożliwiając wykonanie dowolnego SQL.