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.