Dear subscribers,

we're sharing our latest advisory with you and would like to thank everyone who contributed in finding and solving those vulnerabilities. Feel free to join our bug bounty programs (open-xchange, dovecot, powerdns) at HackerOne. Please find patches for v2.2.36 and v2.3.4 attached, or download new version from https://dovecot.org

Yours sincerely, Aki Tuomi Open-Xchange Oy

Product: Dovecot Vendor: Open-Xchange Oy Internal reference: DOV-2890 (Bug ID) Vulnerability type: Improper Authentication - Generic (CWE287) Vulnerable versions: 1.1.0 - 2.2.36 and 2.3.0 - 2.3.4 Vulnerable component: authentication Report confidence: Confirmed Solution status: Fixed by Vendor Fixed versions: 2.2.36.1, 2.3.4.1 Vendor notification: 2019-01-16 Solution date: 2019-01-20 Public disclosure: 2019-02-05 Researcher Credits: https://hackerone.com/halfdog CVE reference: CVE-2019-3814 CVSS: 8.2 (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N)

Vulnerability Details: Normally Dovecot is configured to authenticate imap/pop3/managesieve/submission clients using regular username/password combination. Some installations have also required clients to present a trusted SSL certificate on top of that. It's also possible to configure Dovecot to take the username from the certificate instead of from the user provided authentication. It's also possible to avoid having a password at all, only trusting the SSL certificate.

If the provided trusted SSL certificate is missing the username field, Dovecot should be failing the authentication. However, the earlier versions will take the username from the user provided authentication fields (e.g. LOGIN command). If there is no additional password verification, this allows the attacker to login as anyone else in the system.

This affects only installations using:

auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes

Attacker must also have access to a valid trusted certificate without the ssl_cert_username_field in it. The default is commonName, which almost certainly exists in all certificates. This could happen for example if ssl_cert_username_field is a field that normally doesn't exist, and attacker has access to a web server's certificate (and key), which is signed with the same CA.

Attack can be migitated by having the certificates with proper Extended Key Usage, such as 'TLS Web Server' and 'TLS Web Server Client'.

Also, ssl_cert_username_field setting was ignored with external SMTP AUTH, because none of the MTAs (Postfix, Exim) currently send the cert_username field. This may have allowed users with trusted certificate to specify any username in the authentication. This does not apply to Dovecot Submission service.

Proof of concept

Create a CA certificate for signing, and sign a certificate with missing commoName attribute.

With following configuration

passdb { driver = static arguments = nopassword }

ssl_ca =</path/to/ca.pem auth_ssl_require_client_cert = yes auth_ssl_username_from_cert = yes

You are able to log in as any user with this certificate using following commands:

openssl s_client -connect server:port -cert /path/to/cert -key /path/to/key a LOGIN anyusername anypassword