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@wizmail.org
Reporter: jgg@ziepe.ca
CC: exim-dev@exim.org
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.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
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@wizmail.org
Reporter: jgg@ziepe.ca
CC: exim-dev@exim.org
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.
--
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##