Katalog podatności CVE

@better-auth/sso przed wersją 1.6.27 (oraz przed 1.4.8 w linii 1.4.x i przed 1.7.0-rc.5 w linii 1.7) zawiera dwie wady dotyczące własności domen. Gdy weryfikacja domeny jest wyłączona, automatyczne przypisywanie organizacji akceptuje niezweryfikowane domeny dostawcy, co pozwala uwierzytelnionemu właścicielowi organizacji na zarejestrowanie dostawcy SSO dla dowolnej domeny i dodanie użytkowników z pasującymi domenami e-mail do organizacji atakującego z domyślnymi uprawnieniami członka. Gdy weryfikacja domeny jest włączona, wyścig między endpointami verify-domain i update-provider może zastosować dowód DNS do innej domeny; w połączeniu z niejawnym łączeniem kont może to powiązać dostawcę tożsamości kontrolowanego przez atakującego z istniejącym kontem użytkownika.

GROWI stosuje kontrolę uprawnień do przeglądania strony tylko wtedy, gdy żądanie załącznika zawiera uwierzytelnionego użytkownika. Funkcja retrieveAttachmentFromIdParam pomija kontrolę, gdy użytkownik jest null, więc żądanie bez sesji pomija kontrolę i zwraca plik. Nieuwierzytelniony atakujący, znając identyfikator załącznika, może pobrać plik, nawet jeśli strona jest prywatna. Wersja 8.0.2 sprawdza zarówno uwierzytelnionych, jak i nieuwierzytelnionych użytkowników.

CorvusSKK zawiera podatność na wstrzyknięcie kodu, która może prowadzić do wykonania dowolnego kodu na dotkniętym produkcie.

W systemie FreeBSD 15.0 wykryto podatność w jądrze związaną z nieprawidłową aktualizacją funkcji group_is_primary() podczas zmiany struktury przechowywania identyfikatora grupy głównej. Błąd pozwala, przy użyciu określonych reguł mac_do, na nieprawidłowe ustawienie głównego identyfikatora grupy na wartość z pierwszej pozycji listy grup dodatkowych, co może prowadzić do nadania grupy 0 (wheel).

Implementacja tego ioctl próbuje uzyskać blokady na wszystkich kanałach w grupie synchronizacji. Jeśli zablokowanie kanału by blokowało, zwalnia blokadę listy grupy synchronizacji i usypia. Po ponownym przebudzeniu możliwe jest, że struktura grupy synchronizacji została zwolniona, ale implementacja nie obsłużyła tej możliwości. Na systemie z wieloma urządzeniami audio nieuprzywilejowany użytkownik lokalny może wykorzystać ten use-after-free do eskalacji uprawnień.

Ścieżka odbioru SOCK_STREAM w implementacji gniazd unix nie w pełni odłączała komunikaty sterujące od bufora gniazda przed ich przetworzeniem. Niektóre ścieżki błędów zwalniały te komunikaty, pozostawiając zwolnione mbufy danych w buforze odbiorczym gniazda. Nieuprzywilejowany użytkownik lokalny może wykorzystać ten use-after-free do eskalacji uprawnień.

Gdy proces wywołuje execve(2) w celu wykonania obrazu setuid lub setgid, hwpmc(4) powinien odłączyć PMC należące do nieuprzywilejowanych procesów. Odwrócone sprawdzenie oznaczało, że ten scenariusz nie był obsługiwany prawidłowo. Nieuprzywilejowany użytkownik lokalny, który podłączył PMC do procesu, może kontynuować monitorowanie go po wykonaniu przez proces binarki setuid lub setgid, wbrew zamierzonej polityce.

Compliance-trestle (Trestle) przed wersją 3.12.4 oraz w wersjach 4.0.0-4.0.3 pozwala na zapis dowolnych plików poza obszarem roboczym Trestle poprzez ścieżkę wyjściową kontrolowaną przez atakującego, bez walidacji przejścia ścieżki. Może to prowadzić do nadpisania plików, a przy użyciu --force-overwrite do usunięcia katalogów i pośredniego wykonania kodu.

Compliance-trestle (Trestle) przed wersją 3.12.4 oraz w wersjach 4.0.0-4.0.3 zawiera podatność na wstrzyknięcie szablonów po stronie serwera (SSTI) w niestandardowych tagach Jinja2 mdsection_include i md_clean_include, co może prowadzić do wykonania dowolnego kodu. Dane OSCAL kontrolowane przez atakującego mogą zostać wykonane jako kod szablonu.

Na platformie Trusted Firmware-M (TF-M) 2 do 2.3.0 przed commit 00d1b3e, inicjalizacja skrzynki pocztowej na PSOC64 i RP2350 akceptuje niebezpieczny, niezweryfikowany wskaźnik dostarczony z niebezpiecznego świata.

Compliance-trestle (Trestle) przed wersją 3.12.4 oraz w wersjach 4.0.0 do 4.0.3 ma podatność na obejście walidatora URLSecurityValidator, który chroni ścieżki zdalnego pobierania przed SSRF. Można ominąć blokadę, aby dotrzeć do adresów loopback, link-local, cloud-metadata i wewnętrznych sieci. Problem został naprawiony w wersjach 3.12.4 i 4.1.0.

Podatność polegająca na przesyłaniu poufnych informacji w postaci jawnego tekstu w interfejsie NFC wielu modeli urządzeń IoT Milesight z podatnym oprogramowaniem pozwala nieuwierzytelnionemu atakującemu z fizyczną bliskością na odzyskanie kluczy LoRaWAN ABP NwkSKey i AppSKey oraz kluczy D2D poprzez operację odczytu NFC. Ujawnione klucze mogą być użyte do deszyfrowania ruchu LoRaWAN, fałszowania ramek w górę i w dół, przesyłania sfałszowanych danych z czujników, wydawania poleceń obsługiwanych urządzeń oraz powodowania odrzucania kolejnych prawidłowych ramek.

Wykryto podatność w TOTOLINK N600R 4.3.0cu.7647_B20210106. Dotkniętym elementem jest funkcja getCurrentTime w pliku /cgi-bin/cstecgi.cgi. Manipulacja argumentem ntp_server prowadzi do wstrzyknięcia poleceń. Atak może być przeprowadzony zdalnie. Exploit jest publiczny i może być wykorzystany.

Compliance-trestle (Trestle) to Python SDK i narzędzie wiersza poleceń do zarządzania dokumentami zgodności OSCAL. W wersjach przed 3.12.4 oraz 4.0.0 do 4.0.3 Trestle jest podatny na wstrzyknięcie szablonów po stronie serwera, co może prowadzić do zdalnego wykonania kodu. Dzieje się tak, ponieważ tagi Jinja2 MDCleanInclude i MDSectionInclude ponownie parsują niezaufaną treść Markdown jako kod źródłowy szablonu przy użyciu nieizolowanego środowiska jinja2.Environment. Atakujący, który kontroluje treść renderowaną przez Trestle, taką jak spreparowany plik Markdown w workspace, dokument SSP innej firmy lub wartość tabeli YAML, może wstrzyknąć wyrażenie Jinja2, które przeszukuje wewnętrzne obiekty Pythona w celu wykonania dowolnych poleceń systemu operacyjnego w kontekście procesu Trestle. Problem został naprawiony w wersjach 3.12.4 i 4.1.0.

Podatność na obejście uwierzytelniania przez atak typu capture-replay w Spring Security. DPoPProofJwtDecoderFactory zawiera podatność na atak typu replay oparty na pamięci podręcznej. Wewnętrzna pamięć podręczna przechowująca identyfikatory JWT ma ścisły limit rozmiaru, co pozwala atakującym na usunięcie prawidłowych wpisów przez zalanie serwera fałszywymi żądaniami, a następnie powtórzenie przechwyconych prawidłowych dowodów DPoP.

Moduł Drupal Edit in-place field ma podatność na nieprawidłową autoryzację, która pozwala na wymuszone przeglądanie (Forceful Browsing). Dotyczy wersji od 0.0.0 do 2.1.1.

Moduł Drupal Token Content Access ma podatność na obserwowalną różnicę czasu (Observable Timing Discrepancy), która umożliwia atak brute force. Dotyczy wersji od 0.0.0 do 3.1.2.

W BlueZ, stosie protokołu Bluetooth w systemie Linux, istnieje podatność na przepełnienie bufora oparte na stosie. Zdalny użytkownik w zasięgu radia Bluetooth może wysłać specjalnie spreparowany pakiet Extended Inquiry Response (EIR), który powoduje przepełnienie bufora podczas wykrywania urządzenia Bluetooth przez urządzenie docelowe. Podatność ta może prowadzić do odmowy usługi (DoS) poprzez awarię usługi bluetoothd i może umożliwić wykonanie dowolnego kodu.

W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane za pomocą delegowanych mechanizmów uwierzytelniania (tokeny dostępu OAuth1, poświadczenia aplikacji, zaufania) mogły być przesyłane do ścieżki uwierzytelniania metodą tokena w celu ponownego uwierzytelnienia, aby uciec od zamierzonego zakresu projektu. Gdy token poświadczeń aplikacji został przedstawiony bez jawnego zakresu, Keystone wydawał nowy token o zakresie domyślnego projektu właściciela poświadczeń, a nie projektu, dla którego poświadczenie zostało wydane, omijając zamierzoną granicę projektu. Wszystkie wdrożenia Keystone, które zezwalają na delegowane uwierzytelnianie przez tokeny dostępu OAuth1, poświadczenia aplikacji lub zaufania, są dotknięte.

W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane za pomocą tokena dostępu OAuth1, poświadczeń aplikacji lub uwierzytelniania z zakresem zaufania mogły tworzyć nowe długotrwałe poświadczenia lub autoryzować nowe delegacje, które utrzymują się niezależnie od poświadczenia użytego do ich uzyskania i go przeżywają. Ograniczenia delegacji, które blokują te operacje, nie były spójnie stosowane do wszystkich typów tokenów delegowanych, co pozwalało na przykład tokenowi z zakresem OAuth1 na tworzenie poświadczeń aplikacji lub autoryzację tokenów żądań OAuth1, mimo że te operacje były ograniczone dla innych typów tokenów delegowanych. Wszystkie wdrożenia Keystone, które zezwalają na delegowane uwierzytelnianie przez tokeny dostępu OAuth1, poświadczenia aplikacji lub zaufania, są dotknięte.