Podatności hMailServer

Podatność na wstrzykiwanie kodu JScript w hMailServer (wersje 6.0.0-6.3.3) umożliwia zdalnemu, nieuwierzytelnionemu atakującemu wykonanie dowolnego kodu JScript w procesie usługi z uprawnieniami konta usługi. Wymaga to niestandardowej konfiguracji: włączonego skryptowania zdarzeń, języka JScript i zdefiniowanego handlera OnClientValidatePassword. Atak wykorzystuje hasło zawierające backslash i apostrof, które nie jest poprawnie escapowane.

Nieprawidłowa autoryzacja w API administracyjnym COM w hMailServer 6.3.4–6.3.6 pozwala kontu z rolą serveradmin ograniczoną do listy domen działać jako administrator całego serwera przez COM. Konto może odczytywać i zmieniać konta oraz pocztę wszystkich domen, zmieniać nazwy domen, mapować aliasy, modyfikować ustawienia i sekrety serwera oraz tworzyć kolejne konta administratora serwera.

Brak autoryzacji w interfejsach administracyjnych REST i COM hMailServer 6.0.0–6.3.6 firmy Progressive Robot pozwala zdalnemu uwierzytelnionemu użytkownikowi, którego poświadczenia są ograniczone do wskazanych domen, na zmianę routingu poczty i konfiguracji domen poza tymi domenami na serwerze wielodostępnym. Możliwe jest m.in. utworzenie aliasu domeny dla dowolnej nazwy, zmiana nazwy domeny, ustawienie akcji reguły (bind-to-address, send-using-route, script-function) oraz ustawienie hosta przekazywania domeny na adres w sieci serwera.

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.

Nieprawidłowa autoryzacja w interfejsie administracyjnym REST hMailServer 6.3.4–6.3.6 firmy Progressive Robot pozwala zdalnemu uwierzytelnionemu użytkownikowi z uprawnieniem manage_roles w wskazanych domenach na uzyskanie uprawnień administratora serwera. Trasa DELETE /api/v1/role-assignments/{address} sprawdzała jedynie uprawnienia bieżące, a nie przyszłe, co pozwalało odebrać zawężającą rolę kontu o poziomie administratora serwera i przywrócić jego pełne uprawnienia, a następnie zalogować się jako administrator serwera po wcześniejszej zmianie hasła tego konta.

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.

W hMailServer w wersjach 6.0.0–6.3.6 responder ACME HTTP-01 obsługuje tylko jedno połączenie naraz i czeka do 5 sekund na żądanie. Zdalny nieuwierzytelniony atakujący może otwierać bezczynne połączenia, blokując odpowiedź na żądanie walidacji i powodując niepowodzenie wydania lub odnowienia certyfikatu.

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.

Nieprawidłowe domyślne uprawnienia w instalatorze Windows Progressive Robot hMailServer 6.0.0 do 6.3.6 pozwalają lokalnemu uwierzytelnionemu użytkownikowi na wykonanie kodu jako wysokouprzywilejowane konta serwera pocztowego, gdy produkt jest zainstalowany w folderze, którego uprawnienia są dziedziczone z zapisywalnego katalogu nadrzędnego, takiego jak katalog główny dysku. Instalator umieszcza programy serwera w folderze Bin folderu programu i nie nadaje ani folderowi programu, ani Bin własnych uprawnień, więc dziedziczą one uprawnienia katalogu nadrzędnego. W domyślnej lokalizacji Program Files zwykli użytkownicy otrzymują tylko odczyt i wykonanie i konfiguracja nie jest zagrożona; jednak instalator akceptuje dowolną ścieżkę bez ostrzeżenia, a folder programu w katalogu głównym wolumenu NTFS dziedziczy uprawnienia zapisu dla szerokiej grupy - Authenticated Users (Modyfikuj) w kliencie Windows, Users (tworzenie plików i folderów) w Windows Server. Lokalny użytkownik bez uprawnień administratora może następnie zmienić lub zastąpić program usługi, który działa jako LocalSystem lub jako konto wirtualne usługi, albo programy uruchamiane z podniesionymi uprawnieniami przez administratora z Bin podczas instalacji i konserwacji, albo umieścić bibliotekę w Bin, którą te programy ładują zamiast kopii systemowej, uzyskując wykonanie kodu z tymi uprawnieniami. Domyślna instalacja w Program Files nie jest zagrożona.

Podatność w hMailServer (wersje 6.0.0–6.3.6) polega na braku walidacji nagłówka X-hMailServer-LoopCount, który służy do ograniczania pętli przekazywania i autoresponderów. Atakujący może ustawić wartość ujemną (lub powodującą przepełnienie), co znosi limit i prowadzi do ogromnej liczby iteracji, wypełnienia kolejki i dysku oraz zatrzymania usługi pocztowej. Dodatkowo akcja Sieve notify nie miała żadnego limitu, a możliwość edycji nagłówka przez Sieve lub regułę Set header pozwalała na reset licznika.

Podatność polegająca na braku autoryzacji w akcji Sieve notify (wersje 6.2.22–6.3.6) oraz w akcji Reply reguł pocztowych (wersje 6.0.0–6.3.6) w hMailServer firmy Progressive Robot. Uwierzytelniony użytkownik może wysłać wiadomość przez serwer z dowolnego adresu, ponieważ serwer ustawia nagłówek From na wartość :from z skryptu Sieve lub akcji Reply bez weryfikacji, czy adres należy do konta. Jeśli adres należy do domeny hostowanej na serwerze z włączonym podpisywaniem DKIM, wiadomość zostaje podpisana kluczem tej domeny, co pozwala na sfałszowanie poczty zgodnej z polityką DMARC.

W hMailServer w wersjach 6.0.0–6.3.6 występuje błąd polegający na podpisywaniu kluczem DKIM hostowanej domeny każdej wiadomości już przy pierwszym przejściu, na podstawie nagłówka From, bez weryfikacji pochodzenia ani uwierzytelnienia nadawcy. Umożliwia to zdalnemu nieuwierzytelnionemu atakującemu wysłanie wiadomości z fałszywym adresem From w hostowanej domenie, która zostanie podpisana prawidłowym kluczem DKIM tej domeny i przy dalszym przekazaniu (forward, alias, lista, reguła) przejdzie weryfikację DKIM i DMARC u odbiorców zewnętrznych.

Podatność polegająca na braku autoryzacji w akcji editheader języka Sieve (wersje 6.2.22–6.3.6) oraz w akcji ustawiania wartości nagłówka w regułach pocztowych (wersje 6.0.0–6.3.6) w hMailServer firmy Progressive Robot. Uwierzytelniony użytkownik może zmieniać nagłówki From, Sender, Resent-From, Resent-Sender i DKIM-Signature, a następnie przekierować wiadomość, co pozwala serwerowi wysłać ją w imieniu dowolnego adresu, w tym z podpisem DKIM domeny hostowanej na serwerze. Umożliwia to fałszowanie wiadomości zgodne z DMARC danej domeny.

Niecontrolowane usuwanie wpisów w tabeli sesji przeglądarki w REST API Progressive Robot hMailServer 6.2.28 do 6.3.5 pozwala zdalnemu uwierzytelnionemu użytkownikowi na kończenie sesji innych użytkowników. Tabela sesji przeglądarki, współdzielona przez wszystkie konta, administratora serwera i sesje wsparcia, usuwała najstarszą sesję, gdy była pełna, niezależnie od właściciela, i nie ograniczała liczby sesji przypadających na jedno konto. Użytkownik, który wielokrotnie loguje się własnym hasłem, może utrzymywać tabelę pełną i wylogowywać wszystkie sesje webmail i administracyjne, które są bezczynne przez krótki czas, tak długo, jak kontynuuje.

Niecontrolowane usuwanie wpisów w tabelach oczekujących logowań w REST API Progressive Robot hMailServer 6.3.4 i 6.3.5 pozwala zdalnemu nieuwierzytelnionemu atakującemu na powodowanie niepowodzeń logowań OpenID Connect, SAML i passkey innych użytkowników. Trasy rozpoczynające logowanie jednokrotne i wydające wyzwanie passkey są dostępne bez uwierzytelnienia i przechowują stan oczekujący w ograniczonych tabelach, które usuwały najstarszy wpis, gdy były pełne, niezależnie od tego, kto go rozpoczął. Atakujący, który rozpoczyna logowania kilka razy na sekundę (około sto na sekundę dla passkey), wypycha oczekujące logowania innych użytkowników z tabeli, zanim ich przeglądarka wróci, uniemożliwiając logowanie jednokrotne i passkey tak długo, jak trwają żądania.

Nieprawidłowa walidacja certyfikatów w webmailu hMailServer 6.3.2–6.3.5 pozwala zdalnemu, nieuwierzytelnionemu atakującemu doprowadzić do tego, że poczta S/MIME wysyłana później przez konto do innego korespondenta zostanie zaszyfrowana także kluczem atakującego. Webmail zachowywał certyfikat nadawcy do szyfrowania odpowiedzi niezależnie od tego, czy łańcuch certyfikatów uznano za zaufany, przypisywał go do pierwszego adresu e-mail z certyfikatu zamiast adresu From wiadomości i dodawał go obok już posiadanych certyfikatów dla tego adresu.

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.

Nieefektywna złożoność algorytmiczna w widoku wiadomości webmaila w REST API hMailServer 6.3.2–6.3.5 pozwala zdalnemu, nieuwierzytelnionemu atakującemu unieruchomić webmail, konsolę administracyjną i REST API poprzez wysłanie wiadomości. Trasa renderująca HTML wiadomości zastępowała każde odwołanie do osadzonego obrazu w miejscu, z pracą rosnącą kwadratowo wraz z liczbą odwołań, i zapisywała obraz dla każdego odwołania, licząc go przeciw limitowi rozmiaru tylko raz.

Nieefektywna złożoność algorytmiczna w REST API (6.3.3–6.3.5) oraz w odpowiedzi IMAP PREVIEW (6.2.22–6.3.5) hMailServer pozwala zdalnemu, nieuwierzytelnionemu atakującemu unieruchomić webmail, konsolę administracyjną i REST API poprzez wysłanie wiadomości. Aby pokazać fragment każdej wiadomości na liście w folderze, serwer dekodował odwołania do encji znakowych wiadomości z częścią HTML i bez części tekstowej za pomocą zamiany ciągów, której praca rosła kwadratowo wraz z ich liczbą.

hMailServer 6.0.0–6.3.5 przetwarza kilka poleceń IMAP od zalogowanego konta w czasie kwadratowym względem długości polecenia lub liczby nazwanych elementów i może zostać zmuszony do zajęcia pamięci nieproporcjonalnej do polecenia. Parser elementów danych FETCH normalizował sekcję BODY[] za pomocą zamiany ciągów bez rozróżniania wielkości liter, kopiując cały element przy każdym wystąpieniu, a wyszukiwanie bez rozróżniania wielkości liter porównywało igłę od nowa na każdej pozycji.

Nieefektywna złożoność algorytmiczna w dekodowaniu pól nagłówka wiadomości w hMailServer 6.0.0–6.3.5 pozwala zdalnemu, nieuwierzytelnionemu atakującemu unieruchomić usługi IMAP, SMTP i POP3 lub webmail poprzez wysłanie wiadomości. Serwer rozwijał zdekodowaną wartość nagłówka, znajdując każdy znak nowej linii od końca wartości i usuwając go, przesuwając resztę wartości za każdym razem, więc jego praca rosła kwadratowo wraz z liczbą znaków nowej linii.

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.

Nieprawidłowe rozwiązywanie linków i zewnętrzna kontrola ścieżek plików w administracyjnych operacjach wiersza poleceń hMailServer.exe w hMailServer 6.3.4 i 6.3.5 pozwalają lokalnemu atakującemu, który już wykonuje kod jako konto usługi o niskich uprawnieniach, na eskalację uprawnień. W systemie Windows operacje uruchamiane z uprawnieniami administratora przez instalator, DBSetup, Panel sterowania lub administratora zapisywały wpisy dziennika i rekordy awarii do folderu dziennika, tworzyły, usuwały i zmieniały uprawnienia certyfikatu samopodpisanego i klucza prywatnego w folderze danych oraz przepisywały pliki wiadomości w folderze danych, wszystko według ścieżek w folderach, które konto usługi może modyfikować, podążając za punktami połączenia i montowania.

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 ekspansji makr SPF w hMailServer 6.3.4 i 6.3.5 pozwala zdalnemu nieuwierzytelnionemu atakującemu na obciążenie wątków roboczych poprzez opublikowanie spreparowanego rekordu SPF. Zgodnie z RFC 7208, serwer usuwał etykiety pojedynczo, kopiując resztę nazwy za każdym razem, co powodowało kwadratowy wzrost czasu pracy. Atakujący może sprawić, że sprawdzenie SPF wiadomości z kontrolowanej domeny zajmie kilka sekund, ale ograniczenia SPF powodują częściową utratę dostępności.

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ą.

Nieefektywna złożoność w ocenie filtrów Sieve w hMailServer 6.2.24 do 6.3.5 pozwala uwierzytelnionemu posiadaczowi konta na uczynienie usług pocztowych niedostępnymi za pomocą własnego filtra. Wzorce ':matches' były dopasowywane przez algorytm z nawrotami, którego czas rósł z długością dopasowywanej wartości do potęgi liczby znaków wieloznacznych, a 'deleteheader' usuwał pola pojedynczo, co dawało złożoność O(N^2). Filtry Sieve działają na małym, współdzielonym puli wątków dostarczania, więc aktywny skrypt może wyczerpać pulę i zatrzymać dostarczanie dla całego serwera.

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 szyfrowania Blowfish (BlowFishEncryptor::Encode, wywoływanej przez EncryptToString) w Progressive Robot hMailServer 6.0.0 do 6.3.5 pozwala uwierzytelnionemu użytkownikowi skrzynki pocztowej wywołać odmowę usługi (awarię usługi) i prawdopodobnie inne nieokreślone skutki. W wersjach 6.3.4 i 6.3.5, gdy włączone jest samoobsługowe API REST (domyślnie wyłączone), użytkownik może to zrobić zdalnie, dodając konto pobierania z hasłem o długości od 129 do 247 znaków niebędącej wielokrotnością 8, a następnie żądając eksportu danych osobowych (GET /api/v1/me/export.zip), co szyfruje to hasło starszym schematem. Ta sama wada jest osiągalna w systemie Windows przez dowolnego lokalnego użytkownika interaktywnego bez poświadczeń hMailServer, poprzez metodę COM Utilities.BlowfishEncrypt, która nie sprawdzała uwierzytelnienia. Jest również osiągalna przy każdym zapisie przechowywanego sekretu, gdy ProtectStoredSecretsWithDPAPI jest ustawione na 0. Dla takiej długości pętla dopełniania procedury zapisuje do 7 bajtów zerowych od 2 do 232 bajtów poza końcem bufora sterty o rozmiarze 255 bajtów. Zwracany szyfrogram jest nadal poprawny.

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.