[exim-dev] [Bug 2624] New: When using manualroute TLS certif…

Páxina inicial
Borrar esta mensaxe
Responder a esta mensaxe
Autor: admin
Data:  
Para: exim-dev
Asunto: [exim-dev] [Bug 2624] New: When using manualroute TLS certification is not safe
https://bugs.exim.org/show_bug.cgi?id=2624

            Bug ID: 2624
           Summary: When using manualroute TLS certification is not safe
           Product: Exim
           Version: 4.93
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: security
          Priority: medium
         Component: TLS
          Assignee: jgh146exb@???
          Reporter: jgg@???
                CC: exim-dev@???


If manual route is used to target a user configured server, as in the manual:

smart_route:
driver = manualroute
domains = !+local_domains
transport = remote_smtp
route_list = * smarthost.ref.example

Then exim does a DNA lookup on 'smarthost.ref.example' and if it is a CNAME to
evil.com it generates a host list of something like:

evil.com 1.1.1.1. mx=-1 sort=-489

Finally, when TLS goes to connect it validates that the certificate belongs to
evil.com. This is allowing an undetected man in the middle via only DNS
manipulation with even the strongest TLS settings. When manual route is used in
this way exim should require the ultimate destination present a TLS certificate
for smarthost.ref.example and reject anything else.

Exim's manualroute should not replace the secure user provided hostname with
anything else.

This was noticed while debugging why certificate validation errors happen.
Using route_data=smtp.office365.com and tls_verify_hosts=true exim fails to
connect:

TLS: server cert verification includes hostname: "MNZ-efz.ms-acdc.office.com".
[..]
TLS certificate verification failed: cert name mismatch
TLS session fail: (certificate verification failed)
SMTP(close)>>
set_process_info: 2793602 delivering 1jwOz5-00Bdvf-Ou: just tried
MNZ-efz.ms-acdc.office.com

The logging of "server cert verification includes hostname" is printing
exp_tls_verify_cert_hostnames which is the string passed into
gnutls_x509_crt_check_hostname() for verification.

Exim started using "MNZ-efz.ms-acdc.office.com" after the manualroute:

original list of hosts = 'smtp.office365.com::587' options = ''
expanded list of hosts = 'smtp.office365.com::587' options = ''
set transport remote_smtp_smarthost
finding IP address for smtp.office365.com:587
host=smtp.office365.com port=587
doing DNS lookup
smtp.office365.com in "*"? yes (matched "*")
DNS lookup of smtp.office365.com (A) succeeded
fully qualified name = outlook.ms-acdc.office.com
MNZ-efz.ms-acdc.office.com 52.96.32.178 mx=-1 sort=-489
MNZ-efz.ms-acdc.office.com 52.96.44.162 mx=-1 sort=-360
MNZ-efz.ms-acdc.office.com 52.96.15.2 mx=-1 sort=-350
MNZ-efz.ms-acdc.office.com 52.96.88.98 mx=-1 sort=-137

It switched the user provider smtp.office365.com due to CNAME resolution:

$ dig smtp.office365.com @8.8.8.8
smtp.office365.com.    270    IN    CNAME    outlook.office365.com.
outlook.office365.com.    238    IN    CNAME    outlook.ms-acdc.office.com.
outlook.ms-acdc.office.com. 50    IN    CNAME    MNZ-efz.ms-acdc.office.com.
MNZ-efz.ms-acdc.office.com. 9    IN    A    52.96.62.226


I belive in this case the correct/secure behavior of manualroute would be to
produce a host list of the form:

smtp.office365.com 52.96.32.178 mx=-1 sort=-489
smtp.office365.com 52.96.44.162 mx=-1 sort=-360
[..]

Then gnutls would have smtp.office365.com in exp_tls_verify_cert_hostnames and
verification would pass and CNAME based MIM prevented.

--
You are receiving this mail because:
You are on the CC list for the bug.