Katalog podatności CVE

Rozszerzenie Joomla Gridbox (od balbooa.com) w wersji poniżej 2.20.4.0 zawiera podatność na CSRF w funkcji instalacji języka, ponieważ akcja addLanguage nie wymaga metody POST i nie sprawdza tokena sesji.

Oprogramowanie OctoCloud (od AKIN Software) w wersji od 1.12.06 przed 1.12.07 zawiera podatność na obejście autoryzacji przez klucz kontrolowany przez użytkownika, umożliwiającą dostęp do funkcji nieodpowiednio ograniczonych przez ACL.

hMailServer (od Progressive Robot) w wersjach 6.0.0 do 6.3.5 niepoprawnie obsługuje DANE (RFC 7672) przy wysyłce SMTP, co pozwala atakującemu na wyłączenie DANE dla domeny z podpisem DNSSEC i przechwycenie lub modyfikację wiadomości.

hMailServer (od Progressive Robot) w wersjach 6.3.4 i 6.3.5 zawiera podatność na nieefektywną złożoność algorytmiczną w przetwarzaniu odbić i skarg, co pozwala zdalnemu atakującemu zatrzymać dostarczanie poczty.

hMailServer (od Progressive Robot) w wersjach 6.0.0 do 6.3.5 zawiera podatność na nieefektywną złożoność algorytmiczną i niekończącą się pętlę w przetwarzaniu MIME, co pozwala zdalnemu atakującemu uniemożliwić działanie usług pocztowych.

Nieefektywna złożoność algorytmiczna w weryfikacji podpisów DKIM i ARC w hMailServer 6.0.0 do 6.3.5 pozwala zdalnemu, nieuwierzytelnionemu atakującemu na uniemożliwienie działania usług pocztowych poprzez wysłanie wiadomości. Budowanie kanonicznego nagłówka i wybieranie pól nagłówka wymienionych w tagu h= podpisu zajmowało czas rosnący kwadratowo wraz z rozmiarem nagłówka wiadomości. Wiadomość z wieloma polami nagłówka lub polem złożonym z wielu linii, z podpisem DKIM dla domeny kontrolowanej przez atakującego, zajmuje wątek roboczy na dziesiątki sekund na podpis; do dziesięciu podpisów jest ocenianych na wiadomość przez testy DKIM i DMARC.

Nieefektywna złożoność algorytmiczna w czytniku JSON w hMailServer pozwala zdalnemu, nieuwierzytelnionemu atakującemu na uniemożliwienie działania usług pocztowych. Czytanie obiektu JSON utrzymywało pierwszy z każdego zduplikowanego członu nazwy, przeszukując już przeczytane człony, więc obiekt z N różnych nazw członów kosztował O(N^2): 1 MB zajmował 8,9 sekundy, a 4 MB 300 sekund. Zdalny atakujący dociera do czytnika bez konta, wysyłając spreparowany raport TLS-RPT (do 16 MB po dekompresji) do opublikowanej skrzynki raportów domeny, co jest czytane na wątku dostarczania; kilka takich raportów zajmuje wszystkie wątki dostarczania (domyślnie dziesięć), więc serwer nie dostarcza żadnej poczty, lokalnej ani wychodzącej, przez ponad godzinę na raport.

Nieprawidłowe domyślne uprawnienia w instalatorze Windows hMailServer 6.0.0 do 6.3.5 pozwalają lokalnemu, uwierzytelnionemu użytkownikowi na odczyt danych serwera pocztowego. Instalator tworzył foldery danych, logów, temp, bazy danych i zdarzeń oraz plik konfiguracyjny hMailServer.INI z uprawnieniami dziedziczonymi z folderu instalacyjnego, domyślnie w Program Files, które dają grupie lokalnych użytkowników dostęp do odczytu. Każdy użytkownik, który może zalogować się do komputera, może odczytać każdą przechowywaną wiadomość, logi, wbudowaną bazę danych z hashami haseł kont, gdy usługa jest zatrzymana, oraz plik konfiguracyjny, w tym hasło bazy danych, które jest zapieczętowane tylko kluczem DPAPI maszyny i może być odpieczętowane przez dowolne lokalne konto; z zewnętrzną bazą danych to hasło daje pełną kontrolę nad nią.

Progressive Robot hMailServer w wersjach 6.0.0 do 6.3.5 nie wymusza TLS dla wychodzącej dostawy SMTP do serwera wymiany poczty, którego rekordy TLSA zweryfikowane przez DNSSEC nie zawierają rekordu DANE-EE (użycie 3), wbrew RFC 7672 sekcja 2.2. Serwer używał tylko rekordów DANE-EE i traktował zweryfikowany zestaw rekordów TLSA składający się z DANE-TA (użycie 2) lub innych bezużytecznych rekordów tak, jakby nie opublikowano żadnych rekordów, więc dostawa do takiego hosta spadała do oportunistycznego TLS. Atakujący z aktywną pozycją na ścieżce sieciowej między serwerem a serwerem wymiany poczty odbiorcy może stłumić lub przerwać negocjację STARTTLS i spowodować dostarczenie wiadomości w postaci jawnej, gdzie mogą być odczytane i zmodyfikowane.

Brak autoryzacji na obiektach COM w Progressive Robot hMailServer 6.0.0 do 6.3.5 (tylko Windows) pozwala lokalnemu użytkownikowi interaktywnemu bez poświadczeń hMailServer na odczyt i zapis dowolnych plików jako konto usługi oraz kolejkę poczty jako dowolny nadawca. Usługa rejestruje swoje klasy COM bez uprawnień dostępu lub uruchamiania DCOM i wywołuje CoInitializeSecurity bez deskryptora zabezpieczeń, więc każdy użytkownik zalogowany na konsoli lub przez Remote Desktop może aktywować klasy w działającej usłudze; utworzone w ten sposób hMailServer.Message, jego Attachments i Attachment oraz hMailServer.FetchAccount niosą poświadczenie, które nigdy nie zostało uwierzytelnione. Attachments.Add(path) i Attachment.SaveAs(path) nie wykonywały żadnej kontroli autoryzacji, a Message.Save/Copy i FetchAccount.AccountID/Save nie wykonywały żadnej do 6.3.3, a od 6.3.4 traktowały posiadacza bez poświadczeń jako własnego hosta skryptów zdarzeń serwera. Ponieważ usługa nie personifikuje wywołującego COM, Attachments.Add odczytuje dowolny plik, który konto usługi może odczytać, i zwraca go, Attachment.SaveAs zapisuje wybrane przez atakującego bajty do dowolnej ścieżki, do której może zapisać (w instalacji LocalSystem, wykonanie kodu jako SYSTEM), Message.Save kolejkuje wychodzącą pocztę z dowolnego adresu poza kontrolami SMTP, a FetchAccount dołącza zadanie pobierania poczty do dowolnej skrzynki. Obiekty przekazane przez Application zachowują się tak samo, gdy późniejsze Authenticate na tym Application zawiedzie.

Brak walidacji nagłówka Host i brak ograniczania nieudanych logowań administratora w listenerze REST API Progressive Robot hMailServer 6.0.0 do 6.3.5 pozwalają zdalnemu atakującemu na brute-force hasła administratora serwera przez przeglądarkę administratora za pomocą DNS rebinding. Listener, domyślnie wyłączony i powiązany z loopbackiem, odpowiadał na żądania niezależnie od nagłówka Host, a nieudane logowanie z hasłem administratora z loopbacka nie było automatycznie banowane ani opóźniane. Strona internetowa, której nazwa hosta jest rebindowana na 127.0.0.1, otwarta w przeglądarce na serwerze, może wysyłać uwierzytelnione żądania do listenera, odczytywać odpowiedzi i próbować hasła administratora z pełną prędkością, aż jedno zostanie zaakceptowane, dając atakującemu pełną kontrolę administracyjną nad serwerem pocztowym.

Helper aktualizacji na żywo Linuksa (hmailserver-update) w Progressive Robot hMailServer 6.3.4 i 6.3.5 działa jako root na pliku żądania zapisanym przez nieuprzywilejowane konto usługi hmailserver i pobiera z tego żądania program używany do weryfikacji podpisu aktualizacji AppImage oraz jednostkę systemd do zatrzymania przed odczytaniem plików konta usługi. Atakujący, który już wykonuje kod jako konto usługi hmailserver, na przykład przez inną lukę w serwerze pocztowym, może w ten sposób spowodować wykonanie dowolnego kodu jako root, na dowolnej instalacji Linuksa, gdzie jednostka ścieżki aktualizacji na żywo jest aktywna — domyślnie dla pakietów .deb i .rpm projektu — oraz w instalacjach AppImage uruchamianych pod tą jednostką.

Brak limitów czasu sieci w kompilacjach Linuksa Progressive Robot hMailServer 6.3.0 do 6.3.5 pozwala zdalnemu atakującemu na zajęcie wątków serwera na czas nieokreślony i zatrzymanie wychodzącej dostawy poczty (odmowa usługi). Serwer ustawiał limity czasu gniazd w formie akceptowanej przez Windows, którą Linux odrzuca, a jego klienty HTTPS czytały bez terminu, więc peer, który akceptuje połączenie i nic nie wysyła, trzymał wątek oczekujący tak długo, jak długo połączenie pozostawało otwarte. Pobieranie polityki MTA-STS, domyślnie włączone, odbywa się podczas wychodzącej dostawy do mta-sts.<domena odbiorcy>, więc każdy, kto może zmusić serwer do dostarczenia poczty do domeny przez niego kontrolowanej — na przykład jako nadawca koperty wiadomości, która odbija się — może trzymać wątki dostawy, aż wychodząca dostawa ustanie. Ta sama wada dotyczy zapytania DANE TLSA, żądania tokenu OAuth2, klienta ACME oraz listenerów ManageSieve i metryk, które cichy klient przestaje obsługiwać dla wszystkich innych. Kompilacje Windows nie są dotknięte.

Cross-site scripting w webmailu Progressive Robot hMailServer 6.3.2 do 6.3.5 pozwala zdalnemu atakującemu, który może wysłać użytkownikowi zaszyfrowaną wiadomość, na uruchomienie skryptu w origin webmaila z sesją tego użytkownika. Gdy webmail odszyfrowywał wiadomość S/MIME (od 6.3.2) lub OpenPGP (od 6.3.4) w przeglądarce, oferował każdy odszyfrowany załącznik jako blob URL typu mediów zadeklarowanego dla niego. Kliknięcie zapisywało plik, ale jeśli użytkownik otworzył załącznik w nowej karcie, część zadeklarowana jako text/html była renderowana jako dokument origin webmaila, a jej skrypt mógł odczytać skrzynkę, wysyłać pocztę i zmieniać konto przez REST API. Webmail jest serwowany tylko, gdy REST API jest włączone, co nie jest domyślne.

Przepełnienie bufora na stercie w starszej procedurze deszyfrowania Blowfish (BlowFishEncryptor::DecryptFromString) w Progressive Robot hMailServer 6.0.0 do 6.3.3 na Windows pozwala lokalnemu użytkownikowi interaktywnemu bez poświadczeń hMailServer na zapis wybranych bajtów poza końcem 255-bajtowego bufora sterty w procesie usługi hMailServer, który domyślnie działa jako LocalSystem. Użytkownik robi to, przekazując długi ciąg szesnastkowy do metody COM Utilities.BlowfishDecrypt, która nie sprawdzała uwierzytelnienia. Procedura konwertowała dane wejściowe o dowolnej długości na stały 255-bajtowy bufor przed deszyfrowaniem w miejscu. Skutkiem jest odmowa usługi (awaria usługi) i prawdopodobnie wykonanie kodu z uprawnieniami konta usługi.

W Eclipse Ditto w wersjach 3.6.0 do 3.8.13 oraz 3.9.0 do 3.9.7 interfejs Ditto Explorer UI ładuje konfigurację środowiska, w tym URI API Ditto i ustawienia dostawcy OIDC, z dowolnego adresu URL podanego w parametrze environmentsURL. Złośliwy link może ustawić kontrolowaną przez atakującego władzę OIDC z włączonym autoSso, co prowadzi do kradzieży tokenów dostępu i odświeżania ofiary.

Podatność autoryzacyjna w Apache DolphinScheduler pozwala uwierzytelnionym użytkownikom niebędącym administratorami na pobieranie danych konfiguracyjnych Kubernetes przeznaczonych dla administratorów. Ujawnione dane kubeconfig zawierają poświadczenia, które mogą umożliwić bezpośrednie uwierzytelnienie do API Kubernetes poza DolphinScheduler.

Podatność autoryzacyjna w Apache DolphinScheduler pozwala uwierzytelnionym użytkownikom uzyskać informacje o źródłach danych, do których nie mają uprawnień, poprzez endpointy /unauth-datasource i /authed-datasource. Endpointy te nie egzekwują kontroli dostępu i zwracają wrażliwe informacje o połączeniu, w tym hasła do źródeł danych.

Podatność polegająca na obejściu autoryzacji w Apache DolphinScheduler pozwala uwierzytelnionym użytkownikom na operowanie instancjami zadań w projektach, do których nie mają uprawnień, poprzez endpointy /dolphinscheduler/projects/{projectCode}/task-instances/{taskInstanceId}/stop oraz /savepoint.

Podatność polegająca na obejściu autoryzacji w Apache DolphinScheduler pozwala uwierzytelnionym użytkownikom modyfikować definicje zadań w projektach, do których nie mają uprawnień, poprzez endpoint /dolphinscheduler/projects/{projectCode}/task-definition/{code}/with-upstream. Endpoint nie weryfikuje, czy definicja zadania należy do podanego projektu.