hMailServer vulnerabilities

Eval injection vulnerability in hMailServer (versions 6.0.0-6.3.3) allows a remote, unauthenticated attacker to execute arbitrary JScript in the service process with service account privileges. It requires non-default configuration: event scripting enabled, JScript as script language, and an OnClientValidatePassword handler defined. Exploitation uses a password with backslash and apostrophe that is not properly escaped.

Incorrect authorization in the COM administration API of hMailServer 6.3.4 through 6.3.6 allows an account with the serveradmin role limited to a list of domains to act as the whole-server administrator over COM. Such an account can read and change every domain's accounts and mail, rename domains, map aliases, modify server settings and secrets, and create further server-administrator accounts.

Missing authorization in the REST and COM administration APIs of Progressive Robot hMailServer 6.0.0 through 6.3.6 allows a remote authenticated user whose credential is confined to named domains to change mail routing and domain configuration beyond those domains on a multi-tenant server. This includes creating a domain alias for any name, renaming a domain, setting rule actions (bind-to-address, send-using-route, script-function), and setting the domain's relay host to an address on the server's own network.

In hMailServer 6.0.0 through 6.3.6, the anti-virus attachment-stripping action does not fail securely, allowing a remote unauthenticated attacker to have a message the server's virus scanner found infected delivered to the recipient's mailbox unchanged. With virus scanning enabled and its action set to remove attachments and deliver the text, the server keeps one text part and replaces every attachment with a note. A message whose single part is not text has no part the action could pick out and is delivered as it arrived.

A vulnerability in hMailServer versions 6.0.0 through 6.3.6 insufficiently preserves the original sender when forwarding mail. A remote unauthenticated attacker can send a message with a From address in a hosted domain, and the server will forward it so that it passes SPF and DMARC checks for that domain at other receivers, even though the message did not originally pass DMARC.

In hMailServer versions 6.2.25 through 6.3.6, missing authorization in the REST metrics route allows a remote authenticated user whose credential is confined to named domains to read the server-wide traffic history. GET /api/v1/metrics/history returns server-wide traffic counters over the last 30 days, which carry no domain information.

Incorrect authorization in the REST administration API of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential holds the manage_roles permission in named domains to obtain the server administrator's authority. The DELETE /api/v1/role-assignments/{address} route checked only the credential's current authority, not the resulting authority, so such a credential could remove a narrowing role from a server-administrator-level account and then sign in as the server administrator after setting its password.

Missing authorization in the REST role-management routes of Progressive Robot hMailServer 6.3.4 through 6.3.6 allows a remote authenticated user whose credential is confined to named domains to modify a custom role that accounts in other domains hold, and to create custom roles and delete any that no account holds. The routes that create, update and delete a custom role require the manage_roles permission, which only the serveradmin role holds; but a full-scope API key issued for named domains, and serveradmin assigned with a domain list, are serveradmin confined to those domains and hold manage_roles. The server's authorization gate did not refuse the three role routes to a confined credential and the route named no domain, so a credential issued to one tenant could raise or lower the permissions of a custom role assigned across other tenants.

Use of a less trusted source for the envelope sender in the external-account download of hMailServer 6.0.0 through 6.3.6 allows a remote unauthenticated attacker to have mail they write in the name of a domain the server hosts sent on by the server with an envelope sender at that domain, so that it passes the domain's SPF and DMARC at other receivers. A message the server downloads from an external POP3 or IMAP account has no SMTP envelope of its own, and the server took the address in its From header as its envelope sender, whatever that address was. A forward or redirect of the downloaded message to an outside address then left with that address as its envelope sender, which the Sender Rewriting Scheme leaves alone for a hosted domain, so that the receiver's SPF check passed for the forged domain, aligned even under strict alignment, with no non-default setting, host name record or DMARC policy needed.

Incorrect authorization in the Sender Rewriting Scheme (SRS) of Progressive Robot hMailServer 6.2.1 through 6.3.6 allows a remote attacker to relay mail through the server to outside addresses. With SRS enabled, the server rewrites the envelope sender of mail it forwards to a signed SRS address at the forwarding domain, and passes a bounce to that address back to the original sender; but it took every message to a valid SRS address, whatever its sender, as delivery to a local recipient, so the relay rules and the SMTP authentication they require were not applied, and the message was delivered to the outside address the SRS address encodes. Anyone holding a valid SRS address of the server could have the server relay mail to the address it encodes for 21 days.

In hMailServer 6.0.0 through 6.3.6, the ACME HTTP-01 challenge responder serves only one connection at a time and waits up to five seconds for a request. A remote unauthenticated attacker can hold idle connections open, preventing the certificate authority's validation request from being answered and causing certificate issuance or renewal to fail.

The SMTP server in hMailServer 6.0.0 through 6.3.6 logs credentials that should be hidden, including AUTH PLAIN passwords in certain forms, OAuth 2.0 bearer tokens (XOAUTH2, OAUTHBEARER), the SCRAM-SHA-256 client proof, and the GSSAPI authenticator. A local user able to read the logs, or anyone with a copy, can obtain credentials.

A CSRF vulnerability exists in the REST API of hMailServer 6.0.0 through 6.3.6 because cross-site protection covers only the cookie session, not HTTP Basic authentication. A browser holding cached Basic credentials can be tricked into performing a state-changing request (e.g., creating a domain, account, or API key) from an attacker-controlled site.

Incorrect default permissions in the Windows installer of Progressive Robot hMailServer 6.0.0 through 6.3.6 allow a local authenticated user to run code as the mail server's high-privileged accounts when the product is installed in a folder whose permissions are inherited from a writable parent, such as the root of a drive. The installer places the server's programs in the Bin folder of the program folder and gives neither the program folder nor Bin any permissions of their own, so they inherit the parent's. Under the default location, Program Files, ordinary users receive only read and execute and the configuration is not affected; but the installer accepts any path without warning, and a program folder at the root of an NTFS volume inherits write access for a broad group - Authenticated Users (Modify) on a Windows client, Users (create files and folders) on Windows Server. A local user without administrator rights can then alter or replace the service program, which runs as LocalSystem or as the service's virtual account, or the programs an administrator runs elevated from Bin during setup and maintenance, or place a library in Bin that those programs load in place of the system copy, gaining code execution with those privileges. The default Program Files installation is not affected.

A vulnerability in hMailServer (versions 6.0.0 through 6.3.6) involves unchecked input for the X-hMailServer-LoopCount header, which is used to bound forwarding and auto-reply loops. An attacker can set a negative value (or one that overflows to negative), bypassing the limit and causing a message to loop up to about two billion times, filling the queue and disk and stopping mail service. Additionally, the Sieve notify action had no limit, and the counter could be reset via Sieve editheader or a rule Set header action.

Missing authorization in the Sieve notify action (versions 6.2.22 through 6.3.6) and in the mail-rule Reply action (versions 6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to send mail through the server as any address. The server sets the From header to the :from value from the Sieve script or Reply action without verifying that the address belongs to the account. If the claimed address is at a domain hosted by the server with DKIM signing enabled, the message is signed with that domain's key, producing forged mail aligned to pass the domain's DMARC policy.

hMailServer 6.0.0 through 6.3.6 signs every message on its first delivery pass with the DKIM key of the hosted domain named in the From header, without checking the message origin or sender authentication. A remote unauthenticated attacker can therefore send a message with a forged From address at a hosted domain, have it signed with that domain's valid DKIM key, and upon forwarding (forward, alias, list, rule) have it pass DKIM and DMARC at external receivers.

Missing authorization in the Sieve editheader action (versions 6.2.22 through 6.3.6) and in the mail-rule Set header value action (versions 6.0.0 through 6.3.6) of Progressive Robot hMailServer allows an authenticated user to modify From, Sender, Resent-From, Resent-Sender, and DKIM-Signature headers and then redirect messages, causing the server to send mail as any address, DKIM-signed where the address is at a hosted domain. This enables forgery aligned to pass the domain's DMARC.

Uncontrolled eviction in the browser session table of the REST API in Progressive Robot hMailServer 6.2.28 through 6.3.5 allows a remote authenticated user to end other users' sessions. The table of browser sessions, shared by every account, the server administrator and support sessions, dropped its least recently used session whenever it was full, whoever it belonged to, and placed no limit on how many sessions one account could hold. A user who repeatedly signs in with their own mailbox password can therefore keep the table full and sign out every webmail and administration session that is idle for more than a short time, for as long as they continue.

Uncontrolled eviction in the pending sign-in tables of the REST API in Progressive Robot hMailServer 6.3.4 and 6.3.5 allows a remote unauthenticated attacker to make other users' OpenID Connect, SAML and passkey sign-ins fail. The routes that start a single sign-on and hand out a passkey sign-in challenge are reached without authentication and stored pending state in bounded tables that dropped their oldest entry when full, whoever had started it. An attacker who starts sign-ins a few times a second (about a hundred a second for passkeys) pushes every other user's pending sign-in out of the table before that user's browser returns, denying single sign-on and passkey sign-in for as long as the requests continue.

Improper certificate validation in the webmail of hMailServer 6.3.2 through 6.3.5 allows a remote unauthenticated attacker to have S/MIME-encrypted mail that the account later sends to another correspondent also encrypted to the attacker's key. The webmail kept the signer's certificate for encrypting replies whether or not the server found its chain trusted, under the first e-mail address the certificate listed rather than the message's From address, and beside any certificate already held for that address.

hMailServer (by Progressive Robot) versions 6.0.0 through 6.3.5 fail open when applying DANE (RFC 7672) to outbound SMTP delivery, allowing an attacker to disable DANE for a DNSSEC-signed recipient domain and intercept or modify messages.

Inefficient algorithmic complexity in the webmail's message view of the REST API in hMailServer 6.3.2 through 6.3.5 allows a remote unauthenticated attacker to make the webmail, the administration console and the REST API unavailable by sending a message. The route that renders a received message's HTML replaced each reference to an embedded image in place, with work that grew with the square of the number of references, and wrote the image out for every reference while counting it against its size limit only once.

Inefficient algorithmic complexity in the REST API (6.3.3 through 6.3.5) and the IMAP PREVIEW response (6.2.22 through 6.3.5) of hMailServer allows a remote unauthenticated attacker to make the webmail, the administration console and the REST API unavailable by sending a message. To show a snippet of each message in a folder's message list, the server decoded the character entity references of a message that has an HTML part and no text part with a string replacement whose work grew with the square of their number.

hMailServer 6.0.0 through 6.3.5 processes several IMAP commands from a signed-in account in time quadratic in the command's length or in the number of elements it names, and can be made to hold memory out of proportion to a command. The FETCH data-item parser normalised a BODY[] section with a case-insensitive string replacement that copied the whole item per occurrence and split the item list by repeatedly copying the remainder of the command; the server's case-insensitive search compared a needle afresh at every position.

Inefficient algorithmic complexity in the decoding of message header fields in hMailServer 6.0.0 through 6.3.5 allows a remote unauthenticated attacker to make the IMAP, SMTP and POP3 services, or the webmail, unavailable by sending a message. The server unfolded a decoded header value by finding each line break from the end of the value and removing it, moving the rest of the value each time, so its work grew with the square of the number of line breaks.

hMailServer (by Progressive Robot) versions 6.3.4 and 6.3.5 have inefficient algorithmic complexity in bounce and complaint processing, allowing a remote unauthenticated attacker to stop mail delivery.

Improper link resolution and external control of file paths in the administrative command-line operations of hMailServer.exe in hMailServer 6.3.4 and 6.3.5 allow a local attacker who already runs code as the low-privilege service account to escalate privilege. On Windows, operations run with administrator rights by the installer, DBSetup, the Control Panel or an administrator wrote log entries and crash records into the log folder, created, deleted and changed the permissions of the self-signed certificate and private key in the data folder, and rewrote message files in the data folder, all by path in folders the service account can modify, following junctions and mount points.

hMailServer (by Progressive Robot) versions 6.0.0 through 6.3.5 have inefficient algorithmic complexity and a non-terminating loop in MIME processing, allowing a remote unauthenticated attacker to make mail services unavailable.

Inefficient algorithmic complexity in the inbound DKIM and ARC signature verification of hMailServer 6.0.0 through 6.3.5 allows a remote unauthenticated attacker to make mail services unavailable by sending a message. Building the canonical header and choosing the header fields named in a signature's h= tag took time growing with the square of the message's header. A message with many header fields or a field folded over many lines, with a DKIM-Signature for a domain the attacker controls, keeps a worker thread busy for tens of seconds per signature; up to ten signatures are evaluated per message by each of the DKIM and DMARC tests.

Inefficient algorithmic complexity in SPF macro expansion in hMailServer 6.3.4 and 6.3.5 allows a remote unauthenticated attacker to consume worker-thread time by publishing a crafted SPF record. RFC 7208 requires losing whole labels from the left, but the server did this by removing one label at a time and copying the rest, causing quadratic work. An attacker can make SPF checks take several seconds, but SPF limits bound the expansion, so availability loss is partial.

Inefficient algorithmic complexity in the JSON reader of hMailServer allows a remote unauthenticated attacker to make mail services unavailable. Reading a JSON object kept the first of each duplicated member name by searching the members already read, so an object of N distinct member names cost O(N^2): 1 MB took 8.9 seconds and 4 MB took 300 seconds. A remote attacker reaches the reader without an account by mailing a crafted TLS-RPT report (up to 16 MB after decompression) to a hosted domain's published report mailbox, which is read on a delivery thread; a few such reports hold every delivery thread (ten by default), so the server delivers no mail for over an hour per report.

Incorrect default permissions in the Windows installer of hMailServer 6.0.0 through 6.3.5 allow a local authenticated user to read the mail server's data. The installer created the data, log, temp, database and event folders and the hMailServer.INI configuration file with permissions inherited from the installation folder, by default under Program Files, which give the local Users group read access. Any user who can sign in to the computer could read every stored message, the logs, the built-in database with the accounts' password hashes whenever the service is stopped, and the configuration file, including the database password, which is sealed only with the machine's DPAPI key and can be unsealed by any local account; with an external database that password gives full control of it.

Inefficient complexity in Sieve filter evaluation in hMailServer 6.2.24 through 6.3.5 allows an authenticated account holder to make mail services unavailable with their own filter. ':matches' patterns were matched by backtracking descent with time growing exponentially with wildcards, and 'deleteheader' removed fields one at a time, causing O(N^2) cost. Sieve filters run on the small shared delivery thread pool, so an account holder can empty the pool and stop delivery for the whole server.

Progressive Robot hMailServer 6.0.0 through 6.3.5 does not enforce TLS for outbound SMTP delivery to a mail exchanger whose DNSSEC-validated TLSA records contain no DANE-EE (usage 3) record, contrary to RFC 7672 section 2.2. The server used only DANE-EE records and treated a validated TLSA record set consisting of DANE-TA (usage 2) or otherwise unusable records as if no records were published, so delivery to such a host fell back to opportunistic TLS. An attacker with an active position on the network path between the server and the recipient's mail exchanger can suppress or break the STARTTLS negotiation and cause messages to be delivered in cleartext, where they can be read and modified.

Missing authorization on COM objects in Progressive Robot hMailServer 6.0.0 through 6.3.5 (Windows only) lets a local interactive user with no hMailServer credential read and write arbitrary files as the service account and queue mail as any sender. The service registers its COM classes with no DCOM access or launch permission and calls CoInitializeSecurity with no security descriptor, so any user logged on at the console or over Remote Desktop can activate the classes in the running service; a hMailServer.Message, its Attachments and Attachment, and a hMailServer.FetchAccount created this way carry a credential that never authenticated. Attachments.Add(path) and Attachment.SaveAs(path) performed no authorization check, and Message.Save/Copy and FetchAccount.AccountID/Save performed none either up to 6.3.3 and from 6.3.4 treated a holder with no credential as the server's own event-script host. Because the service does not impersonate the COM caller, Attachments.Add reads any file the service account can read and returns it, Attachment.SaveAs writes attacker-chosen bytes to any path it can write (on a LocalSystem installation, code execution as SYSTEM), Message.Save queues outbound mail from any address past the SMTP checks, and FetchAccount attaches a mail-fetch job to any mailbox. The objects an Application handed out behave the same once a later Authenticate on that Application fails.

Missing Host header validation and missing throttling of failed administrator sign-ins in the REST API listener of Progressive Robot hMailServer 6.0.0 through 6.3.5 allow a remote attacker to brute-force the server administrator's password through the administrator's own browser by DNS rebinding. The listener, which is off by default and bound to the loopback when enabled, answered requests whatever their Host header named, and a failed sign-in with the administrator's password from the loopback was neither auto-banned nor delayed. A web page whose host name the attacker rebinds to 127.0.0.1, opened in a browser on the server, can therefore send authenticated requests to the listener, read the answers and try administrator passwords at full speed until one is accepted, giving the attacker full administrative control of the mail server.

The Linux live-update apply helper (hmailserver-update) of Progressive Robot hMailServer 6.3.4 and 6.3.5 runs as root on a request file written by the unprivileged hmailserver service account, and took from that request the program used to verify an AppImage update's signature and the systemd unit to stop before reading the service account's files. An attacker who already runs code as the hmailserver service account, for example through another flaw in the mail server, can therefore have arbitrary code executed as root, on any Linux installation where the live update's path unit is active - the default for the project's .deb and .rpm packages - and on AppImage installations run under that unit.

Missing network timeouts in the Linux builds of Progressive Robot hMailServer 6.3.0 through 6.3.5 allow a remote attacker to hold server threads indefinitely and so stop outbound mail delivery (denial of service). The server set its socket timeouts in the form Windows takes, which Linux refuses, and its HTTPS clients read without a deadline, so a peer that accepts a connection and then sends nothing held the waiting thread for as long as the connection stayed open. The MTA-STS policy fetch, enabled by default, is made during outbound delivery to mta-sts.<recipient domain>, so anyone who can make the server deliver mail to a domain they control - for example as the envelope sender of a message that bounces - can hold delivery threads until outbound delivery stops. The same flaw affects the DANE TLSA query, the OAuth2 token request, the ACME client, and the ManageSieve and metrics listeners, which a silent client stops from serving anyone else. Windows builds are not affected.

Cross-site scripting in the webmail of Progressive Robot hMailServer 6.3.2 through 6.3.5 allows a remote attacker who can send a user an encrypted message to run script in the webmail's origin with that user's session. When the webmail decrypted an S/MIME message (from 6.3.2) or an OpenPGP message (from 6.3.4) in the browser, it offered each decrypted attachment as a blob URL of the media type the message declared for it. A click saved the file, but if the user opened the attachment in a new tab, a part declared as text/html was rendered as a document of the webmail's origin and its script could read the mailbox, send mail and change the account through the REST API. The webmail is served only when the REST API is enabled, which it is not by default.

Heap-based buffer overflow in the legacy Blowfish encryption routine (BlowFishEncryptor::Encode, called by EncryptToString) in Progressive Robot hMailServer 6.0.0 through 6.3.5 allows an authenticated mailbox user to cause a denial of service (service crash), and possibly other unspecified impact. In 6.3.4 and 6.3.5, where the self-service REST API is enabled (it is off by default), the user does this remotely by adding a fetch account whose password is 129 to 247 characters long and not a multiple of 8, and then requesting their personal data export (GET /api/v1/me/export.zip), which encrypts that password with the legacy scheme. The same flaw is reachable on Windows by any local interactive user with no hMailServer credentials, through the COM method Utilities.BlowfishEncrypt, which checked no authentication. It is also reachable by every stored-secret write when ProtectStoredSecretsWithDPAPI is set to 0. For such a length, the routine's padding loop writes up to 7 zero bytes 2 to 232 bytes past the end of its 255-byte heap buffer. The ciphertext it returns is still correct.

Heap-based buffer overflow in the legacy Blowfish decryption routine (BlowFishEncryptor::DecryptFromString) in Progressive Robot hMailServer 6.0.0 through 6.3.3 on Windows allows a local interactive user with no hMailServer credentials to write bytes of their choosing past the end of a 255-byte heap buffer in the hMailServer service process, which runs as LocalSystem by default. The user does this by passing a long hexadecimal string to the COM method Utilities.BlowfishDecrypt, which checked no authentication. The routine converted hexadecimal input of any length into a fixed 255-byte buffer before decrypting it in place. The result is a denial of service (service crash), and possibly code execution with the privileges of the service account.