Katalog podatności CVE

Podatność w silniku detekcji Teredo w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3, powodując przerwę w inspekcji pakietów. Przyczyną jest niekompletne sprawdzanie błędów podczas parsowania pakietów Teredo przez Snort 3. Wysłanie spreparowanego pakietu Teredo do urządzenia docelowego może wywołać nieoczekiwany restart i stan DoS.

Podatność w silniku detekcji GRE (Generic Routing Encapsulation) w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3, powodując przerwę w inspekcji pakietów. Przyczyną jest niekompletne sprawdzanie błędów podczas parsowania pakietów GRE przez Snort 3. Wysłanie spreparowanego pakietu GRE do urządzenia docelowego może wywołać nieoczekiwany restart i stan DoS.

Podatność w silniku detekcji NetFlow w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3, powodując przerwę w inspekcji pakietów. Przyczyną jest niekompletne sprawdzanie błędów podczas parsowania pakietów UDP Netflow Protocol przez Snort 3. Wysłanie pojedynczego spreparowanego pakietu Netflow przez ustanowione połączenie może wywołać nieoczekiwany restart i stan DoS.

Podatność w dekoderze SMTP MIME w Snort 3 w wielu produktach Cisco pozwala nieuwierzytelnionemu zdalnemu atakującemu na restart silnika detekcji Snort 3. Przyczyną jest brak sprawdzania błędów podczas parsowania pól MIME w nagłówku SMTP. Wysłanie spreparowanych pakietów SMTP przez ustanowione połączenie może wywołać nieoczekiwany restart i stan odmowy usługi (DoS).

W projekcie oretnom23 file-management-system-php (do wersji 2e3c1ebe60f121e8df4fb3f544f0e9591d9a01e4) funkcja delete_folder w pliku ajax.php (komponent AJAX Handler) nie wymaga uwierzytelnienia przy manipulacji argumentem ID. Podatność można wykorzystać zdalnie, a publiczny exploit jest już dostępny.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 żądania otwarcia zewnętrznych adresów URL protokołów mogły być przypisane do innego dokumentu niż ten, który je zainicjował. Powodowało to, że parametr requestingUrl przekazywany do session.setPermissionRequestHandler wskazywał zaufaną treść dla żądania pochodzącego z niezaufanej treści.

Electron to framework do tworzenia aplikacji desktopowych. W wersjach przed 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.5 sprawdzanie uprawnień hid i usb wykonywane z iframe powodowało, że setPermissionCheckHandler otrzymywał origin i szczegóły ramki najwyższego poziomu zamiast ramki żądającej. Aplikacja, która delegowała hid lub usb do niezaufanego iframe cross-origin i zezwalała na dostęp do urządzeń na podstawie logiki origin, mogła przyznać tej osadzonej ramce dostęp przeznaczony dla strony najwyższego poziomu.

Biblioteka klienta Slack Morphism w wersjach 1.0.0–2.27.0 ujawnia poprawny HMAC żądania Slack, gdy weryfikacja podpisu się nie powiedzie. Dla nieprawidłowego żądania biblioteka oblicza poprawny podpis dla kontrolowanego przez atakującego znacznika czasu i treści i zapisuje go w SlackEventWrongSignatureError.generated_hash, a domyślny handler błędów Axum loguje tę wartość. Atakujący mogący dotrzeć do endpointu callback i czytać logi może użyć weryfikatora jako oracle HMAC i w ciągu pięciu minut odesłać żądanie z poprawnym podpisem.

W frameworku Electron żądania uprawnień pointerLock z niektórych iframe'ów cross-origin powodowały, że session.setPermissionRequestHandler() otrzymywał requestingUrl i isMainFrame ramki najwyższego poziomu zamiast wartości ramki żądającej. Aplikacja osadzająca niezaufaną zawartość iframe i przyznająca pointer lock na podstawie pochodzenia żądania mogła przyznać uprawnienie w imieniu strony najwyższego poziomu. Problem naprawiono w wersjach 42.11.9, 43.7.6, 44.5.0 i 45.0.0-alpha.13.

W Electronie przed wersjami 42.11.3, 43.7.0, 44.3.0 i 45.0.0-alpha.6 strony otwierane w nowym oknie z linków były traktowane jako nawigacje zainicjowane przez aplikację, zamiast zachowania strony zawierającej link jako inicjatora. Powodowało to, że żądanie najwyższego poziomu mogło zostać zaklasyfikowane jako same-site, wysyłając ciasteczka SameSite=Strict i nie ujawniając inicjatora w Sec-Fetch-Site.

W hMailServer 6.0.0 do 6.3.6 akcja usuwania załączników przez antywirusa nie kończy się bezpieczną odmową, co pozwala zdalnemu nieuwierzytelnionemu atakującemu na dostarczenie do skrzynki odbiorcy wiadomości uznanej przez skaner za zainfekowaną w niezmienionej postaci. Gdy skanowanie jest włączone, a akcja ustawiona na usuwanie załączników i dostarczanie tekstu, serwer zachowuje jedną część tekstową i zastępuje załączniki notatką. Wiadomość, której jedyna część nie jest tekstem, nie ma części do wyodrębnienia i jest dostarczana bez zmian.

Podatność w hMailServer (wersje 6.0.0–6.3.6) polega na niewystarczającym zachowaniu oryginalnego nadawcy przy przekazywaniu wiadomości. W wyniku tego zdalny, nieuwierzytelniony atakujący może wysłać wiadomość z adresem From w domenie hostowanej przez serwer, a serwer przekaże ją dalej w taki sposób, że u odbiorców przejdzie ona kontrolę SPF i DMARC dla tej domeny, mimo że oryginalnie nie przeszła DMARC.

W hMailServer w wersji od 6.2.25 do 6.3.6 brakuje autoryzacji w trasie REST metrics, co pozwala uwierzytelnionemu użytkownikowi z uprawnieniami ograniczonymi do nazwanych domen odczytać historię ruchu całego serwera. GET /api/v1/metrics/history zwraca liczniki ruchu z ostatnich 30 dni, które są ogólnoserwerowe i nie zawierają informacji o domenie.

Brak autoryzacji w trasach REST do zarządzania rolami w Progressive Robot hMailServer 6.3.4 do 6.3.6 pozwala zdalnemu uwierzytelnionemu użytkownikowi, którego poświadczenia są ograniczone do nazwanych domen, modyfikować rolę niestandardową posiadaną przez konta w innych domenach oraz tworzyć i usuwać role. Trasy tworzenia, aktualizacji i usuwania roli wymagają uprawnienia manage_roles, które posiada tylko rola serveradmin; jednak klucz API o pełnym zakresie wydany dla nazwanych domen oraz serveradmin przypisany z listą domen są ograniczone do tych domen i posiadają manage_roles. Bramka autoryzacji nie odrzuciła tych tras dla ograniczonych poświadczeń, a trasa nie wskazywała domeny, więc poświadczenie jednego tenanta mogło podnieść lub obniżyć uprawnienia roli niestandardowej przypisanej w innych tenantach.

W hMailServer w wersjach 6.0.0–6.3.6 użyto mniej zaufanego źródła adresu koperty przy pobieraniu z konta zewnętrznego. Umożliwia to zdalnemu nieuwierzytelnionemu atakującemu wysłanie wiadomości w imieniu domeny hostowanej przez serwer z adresem koperty w tej domenie, dzięki czemu przechodzi ona kontrolę SPF i DMARC u odbiorców. Serwer przyjmował adres z nagłówka From jako adres koperty dla wiadomości pobranych przez POP3/IMAP, a przekierowanie takiej wiadomości na zewnątrz zachowywało ten adres, który Sender Rewriting Scheme pozostawiał bez zmian dla domeny hostowanej.

Nieprawidłowa autoryzacja w Sender Rewriting Scheme (SRS) w Progressive Robot hMailServer 6.2.1 do 6.3.6 pozwala zdalnemu atakującemu na przekazywanie poczty przez serwer na zewnętrzne adresy. Gdy SRS jest włączony, serwer przepisuje kopertę nadawcy na podpisany adres SRS w domenie przekazującej i przekazuje odbicie na ten adres z powrotem do oryginalnego nadawcy; jednak każdą wiadomość na prawidłowy adres SRS, niezależnie od nadawcy, traktował jako dostarczenie do lokalnego odbiorcy, więc reguły przekazywania i wymagane uwierzytelnianie SMTP nie były stosowane, a wiadomość była dostarczana na zewnętrzny adres zakodowany w adresie SRS. Każdy posiadający prawidłowy adres SRS serwera mógł przez 21 dni zlecać serwerowi przekazywanie poczty na adres, który koduje.

Serwer SMTP w hMailServer 6.0.0 do 6.3.6 zapisuje w logach dane uwierzytelniające, które powinny być ukryte — m.in. hasła AUTH PLAIN w niektórych formach, tokeny OAuth 2.0 (XOAUTH2, OAUTHBEARER), dowód klienta SCRAM-SHA-256 oraz mechanizm GSSAPI. Lokalny użytkownik mogący czytać logi lub posiadacz ich kopii może uzyskać poświadczenia.

W REST API serwera hMailServer w wersjach 6.0.0–6.3.6 występuje podatność CSRF, ponieważ ochrona przed żądaniami cross-site obejmuje tylko sesję cookie, a nie uwierzytelnianie HTTP Basic. Przeglądarka przechowująca poświadczenia Basic może wykonać żądanie zmieniające stan (np. utworzenie domeny, konta lub klucza API) z witryny atakującego.

W Velneo vServer występuje podatność nieprawidłowego rozwiązywania dowiązań przed dostępem do pliku (link following). Problem dotyczy wersji od 32.3 przed 36.6 oraz od 37.1 przed 37.2.

W oprogramowaniu oretnom23 file-management-system-php do wersji 2e3c1ebe60f121e8df4fb3f544f0e9591d9a01e4 wykryto podatność w funkcji include w pliku index.php. Manipulacja argumentem page może prowadzić do włączenia pliku. Atak może być przeprowadzony zdalnie, a exploit został publicznie ujawniony i może być wykorzystany. Produkt działa w modelu rolling release, więc brak szczegółów wersji.