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.
