Hi, > If we're changing `$host` based upon CNAMEs in DNS, then yes this will > do The Wrong Thing. It might be a security problem then, because the > normally-insecure DNS changes the name we validate the certificate > against. We can't rely upon DNSSEC for this default example config.
Yes, that is indeed a security problem that I reported more than a year ago via direct email to Jeremy Harris (unfortunately, I couldn't find any guidelines as to how to report vulnerabilities on the website, and I didn't want to post it publicly), but I unfortunately never heard back from him. When investigating now whether it had been fixed or what to do about it, I stumbled upon this thread, so I guess this is the right place to post this ... So, yes, Exim does check certificates against DNS CNAME targets and is thus vulnerable to MitM attackers retargeting supposedly TLS-protected connections to hostnames that they control and thus can obtain certificates for via spoofed DNS responses when the lookup is not protected by DNSSEC. I successfully tested the attack against the Debian stretch Exim (4.89), and based on the code it does not look like the current git master is any less vulnerable. It only seems that the behaviour is kinda documented now if you look really closely (section "Configuring an Exim client to use TLS" mentions that the name "in the DNS A record" is checked), but that's both incorrect (works with AAAA as well) and easily overlooked. And in any case documenting a vulnerability doesn't make it any less of a vulnerability, as there doesn't seem to be any alternative way to configure things that would be secure. Apart from the fact that this is a vulnerability, it's also functionally broken as it breaks certificate verification when delivering to a smarthost that happens to be a legitimate CNAME, as the correct server certificate, of course, is for the user-specified name (something slightly different might apply when DANE is used). As mentioned elsewhere in this thread, CNAMEs for outbound relays are common with the big providers, so you cannot even enable certificate validation when talking to them unless you hard code the IP addresses in your local hosts file to prevent Exim from seeing the CNAME. When looking at the code now, I noticed another bug and potential vulnerability: verify_callback() in tls-openssl.c treats the hostname as a list. Currently, you can, of course, inject a list via a CNAME response--I have no clue what other ways there might be to exploit this, but it doesn't seem like a good idea anyway. Also, overwriting an admin-supplied value with potentially untrusted information seems to me like a bad idea in general, not just for TLS certificate checking, as that can lead to all sorts of confused deputy style problems if you aren't extremely careful, where policies suddenly are applied based on an identity selected by the attacker rather than what was specified by the admin. Regards, Florian -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##