916281 - pop3/imap/smtp servers should always be resolved as FQDNs

Status: NEW

(Thunderbird :: Security, defect)

Description

[bjoern]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 2013081600

Steps to reproduce:

this bug is related to bug #804619.

Thinking about the FQDN hostname resolving I think that pop3/imap/smtp servers should always and only be resolved as FQDN (with trailing dot) so that the DNS search list is not used for those servers.

Imagine:

- User has saved login/password for his mail accounts in Thunderbird

- User logs in to an untrusted network where an attacker sets the DNS seach list to
  example.com and the attacker sets up a fake IMAP/SMTP server with the DNS name
  smtp.gmail.com.example.com and the attacker blocks the right DNS response for
  smtp.gmail.com

- thunderbird will connect to smtp.gmail.com.example.com and send
  login/password to that fake server, so that the attacker can collect the
  logins and passwords of users

To stop this kind of attacks Thunderbird should generally only make FQDN name
lookups of pop3/imap/smtp servers as FQDN (with trailing dot).

You might argue that such an attack is also possible by manipulating the DNS
reply of let's say smtp.gmail.com completely. But manipulating the DNS reply of
the FQDN of smtp.gmail.com is actually a different attack path which should be
prevented differently, for example by usind DNSSEC and client site DNSSEC-capablity caching. The DNS search list attach cannot be fixed by DNSSEC.

The attack path of setting up smtp.gmail.com.example.com could be worked around
by making realy FQDN-only lookups for servers in Thunderbird. Actually I think Mozilla
should make sure that all the saved credentials are generally only used on hosts
where the *FQDN* matches the hostname saved with the login credentials.

Comment 1

[bjoern]

the first comment should read: This bug is related to bug #913785

Comment 2

[:aceman]

But what if the server name is intentionally input as just a hostname (e.g. 'mailserver') with the expectation that is will be resolved using the search list to some internal company server, e.g. mailserver.company.com ? I am not sure this works or if enterprises use this form, but may be possible.

Comment 3

[bjoern]

those setups are broken and threatened by the possibility of such phishing attacks anyhow. With the opeing of the top level domain name space many of those non-FQDN short DNS names *will* become valid domain names, see https://en.wikipedia.org/wiki/Top-level_domain#Proposed_domains - thousands of new top-level domains will pop up soon that will break a lot of setups that relied on DNS search list instead of FQDN names. "mail", "server" etc. will be valid existing to level domains soon.

I think even if the change to treating the server names as FQDN only would break some setups that rely on DNS search list, it is better to break them and make the majority of other setups secure against this password phishing attack.

The opening of the top level domains will break the setups that rely on search DNS list anyway, sooner or later. A error message that tells the user that server names have to be FQDNs when a server name cannot be resolved would be be a helpful hint to fix the issue.

Comment 4

[Daniel Veditz [:dveditz]]

If you're talking to a server securely then hopefully the "wrong" server won't be able to get a fraudulent cert for your intended domain. If it's not a secure connection then a DNS search is the least of your problems.

Since this is likely to break at least some people it's probably better to discuss such a change in public.

Comment 5

[bjoern]

(In reply to Daniel Veditz [:dveditz] from comment #4)
> If you're talking to a server securely then hopefully the "wrong" server
> won't be able to get a fraudulent cert for your intended domain.

in that attack scenario it is easy for the attacker to offer a legitimate ssl encrypted server. In the network the dns search list attacker-owned-domain.com is bein propagated. The attacker can easily even get a trusted cert for *.attacker-owned-domain.com from any CA. A client who configured a mail server like "mail" will happily connect to the trusted server "mail.attacker-owned-domain.com" then. This is straight forward trivial to do unfortunately


> If it's not
> a secure connection then a DNS search is the least of your problems.

then you have another problem, right, but independent of this.


> Since this is likely to break at least some people it's probably better to
> discuss such a change in public.

as said above, not only this change, also the new generic toplevel domains will break those setups with short dns names

Comment 6

[[e-mail]]

(In reply to bjoern from comment #5)
> (In reply to Daniel Veditz from comment #4)
> > If you're talking to a server securely then hopefully the "wrong" server
> > won't be able to get a fraudulent cert for your intended domain.
> in that attack scenario it is easy for the attacker to offer a legitimate
> ssl encrypted server. In the network the dns search list
> attacker-owned-domain.com is bein propagated. The attacker can easily even
> get a trusted cert for *.attacker-owned-domain.com from any CA. A client who
> configured a mail server like "mail" will happily connect to the trusted
> server "mail.attacker-owned-domain.com" then. This is straight forward
> trivial to do unfortunately
The DNS search list is irrelevant, the client still needs the certificate to match the name that it's configured to connect to. In the case of smtp.gmail.com the OS might resolve it to smtp.gmail.com.untrusted.net and obtain a bogus IP address for it but it won't match a *.untrusted.net certificate.