#11635: dovecot-2.3.4.1 (CVE-2019-3814)
-------------------------+-----------------------
Reporter: bdubbs | Owner: renodr
Type: enhancement | Status: assigned
Priority: high | Milestone: 8.4
Component: BOOK | Version: SVN
Severity: normal | Resolution:
Keywords: |
-------------------------+-----------------------
Comment (by renodr):
{{{
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
}}}
--
Ticket URL: <http://wiki.linuxfromscratch.org/blfs/ticket/11635#comment:3>
BLFS Trac <http://wiki.linuxfromscratch.org/blfs>
Beyond Linux From Scratch
--
http://lists.linuxfromscratch.org/listinfo/blfs-book
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
