Improper Certificate Validation in hMailServer
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| Progressive Robot Ltd | hMailServer | unaffected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Progressive Robot | Hmailserver |
|
Vendor Solution
Upgrade to hMailServer 6.3.8, which reads Server= as MariaDB Connector/C does and refuses TlsMode=verify-full with no TlsCaFile before connecting, with HM7535 in the error log, on a connection the client treats as local or a Server= list that holds one, and which says, on such a connection with a TlsCaFile, that the certificate's issuer was checked and not its name. Until then, set TlsCaFile to a file holding only the CA that issues the database server's certificate, at a path in ASCII alone; the client then checks the certificate's issuer on such a connection, though not its name. On these versions the --check-database settings line and the application log say the certificate was checked either way, so they do not show the difference.
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.083% probability within 30 days)
Key SSVC decision points have not yet been added.
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Progressive Robot
Progressive Robot hmailserver |
|
| Vendors & Products |
Progressive Robot
Progressive Robot hmailserver |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | Progressive Robot hMailServer 6.3.4 through 6.3.7, with a MySQL or MariaDB database, TlsMode=verify-full and no TlsCaFile, does not verify the database server's certificate's issuer or name when the connection is one that MariaDB Connector/C treats as local - Server= set to 127.0.0.1, ::1 or localhost (on Linux a Unix socket), to . on Windows (a named pipe), or to a comma-separated list of servers that holds such an element - which allows a local attacker who can stand in for the database server, for example by listening on its port while it is stopped or restarting, to receive the database sign-in, the password included, and to read and modify the traffic between hMailServer and its database. hMailServer applied verify-full by turning the client's certificate verification on without a CA file, but MariaDB Connector/C 3.4.1 and later, on a connection they treat as local and with no CA file, accept any certificate within its validity period that is self-signed or sent with its own root, for any name (Connector/C 3.4.2 to 3.4.10 also one whose issuer they cannot find), so the client accepted the certificate an impostor made, asked no proof of the password and allowed a switch to an authentication method that sends the password unhashed, while hmailserver --check-database said the certificate had been checked against the system's trust store and the application log that it had been checked. The Windows builds bundle Connector/C 3.4.9 (6.3.4 to 6.3.6) and 3.4.11 (6.3.7); on Linux the distribution's client is used, and Connector/C 3.3 and 3.4.0 and Oracle's MySQL client are not affected. The configuration is not the default: TlsMode defaults to prefer, which checks no certificate. | |
| Title | Improper Certificate Validation in hMailServer | |
| Weaknesses | CWE-295 | |
| References |
| |
| Metrics |
cvssV3_1
|