autoconfig security
Ben Bucksch
intended to be able to automatically figure out the mail settings needed
to configure an email account, like hostnames, ports, SSL on/off, secure
auth algo etc.. All that the user should need to provide is his real
name, email address and password. We take the domain of the email
address and try to find the configuration from that.
Please see
https://wiki.mozilla.org/Thunderbird:Autoconfiguration#Implementation
I think that's fairly secure (and specifically designed to be). We try
to get the config only by contacting servers at the original domain
example.net (or Mozilla), and that should be under the control of the
mail provider Example Corp. We also try to do that only via secure
mechanisms (which is a pain, because it rules out DNS).
philor, during review, asked for a "formal security review" by the
Mozilla Security Group, so that's what this post is about.
The risk here is that we find and offer a configuration that contains
mail servers operated by an attacker. E.g. Emily wants to set up
em...@example.net, but we find a configuration for example.net that
includes imap.evil.com. Then, evil.com would gain Emily's email
password. Or imap.example.net offers SSL, but the attacker manages to
return a config without SSL nor password encryption, and then using a
MITM to read the cleartext password.
Mitigating factors are:
* There is a small time window for the attacker. It's all only about
the account setup wizard, and setting up an account is a very rare
action, 2 times per year roughly on average.
* The attacker has to run a MITM or DNS attack of some sort.
* We show the configuration (hostnames etc.) to the user before we
create the account, and do not send the password before the user
clicked "Create account".
* The greatest possible danger here is a loss of the email password.
Addons/Extensions or downloads of EXEs pose a *far* far larger
risk. Therefore, we should be careful, but not overly hesitant.
Philor came up with one possibly problematic case: A webhoster which is
allowing customers to register subdomains. So, a customers has
fr...@hoster.com and fred.hoster.com. How, if the attacker registers
autoconfig.hoster.com, it can redirect Fred to imap.evil.com and get the
password.
I can see two possible counter-measures for that:
1) The webhoster must block the autoconfig subdomain or register/use it
himself.
2) We also contact https://www.<domain>/autoconfig/mail/mozilla.xml
/before/ we contact autoconfig.<domain>.
Upside of 2) is that it's a bit easier to set up (no new host). Downside
is that it creates more 404 spam in the hoster's logfile (same as
/favicon.ico, which I hate).
Microsoft has a very, very similar feature in Outlook / Exchange 2007,
which also contacts "https://<domain>/autodiscover/autodiscover.xml" and
"https://autodiscover.<domain>/autodiscover/autoodiscover.xml", so they
do exactly the same (same idea independently), and they used 2) above.
(There are some differences in the XML files, so dropping our own format
in favor of Microsoft's is not a good idea, but I plan to implement the
autodiscover as well, in case we talk to Exchange 2007 servers).
Somebody can see other problematic situations?
Ben Bucksch
> Mitigating factors are:
Also, thinking about it:
The vast majority of users currently use no SSL and no "secure auth",
because that's too cumbersome to set up without knowing which
combination works, and official instructions are usually imcomplete and
outdated.
So, people are already sending their password in the clear, the attacker
just has to sniff it. Given that the risk here is that the passwords
gets discovered, and that requires an active attack, I don't think we
can make the situation much worse than now.
This feature can make the situation much better, though, by configuring
SSL for a lot of users where their provider offers it, but is not vocal
about it.
Nikolay Shopik
> All that the user should need to provide is his real name
I'm wonder why this can't be used from current logged on username in
first place. I know this works in Linux and Mac OS X but not on Windows
platform.
Santosh
I don't think this helps, users with multiple email accounts can't
create user for each account. Even creating multiple users in the system
is not possible if a user is using ADS in a corporate network.
Cheers,
Santosh
Nikolay Shopik
> I don't think this helps, users with multiple email accounts can't
> create user for each account. Even creating multiple users in the system
> is not possible if a user is using ADS in a corporate network.
I'm not saying we should force this, but just use Full Name of current
logged on user, if need user will edit it.
JarrE
> intended to be able to automatically figure out the mail settings needed
> to configure an email account, like hostnames, ports, SSL on/off, secure
> auth algo etc.. All that the user should need to provide is his real
> name, email address and password. We take the domain of the email
> address and try to find the configuration from that.
Curiosity:
Is this meant as additional or instead of the existing autoadmin?
lockPref("autoadmin.refresh_interval", time);
lockPref("autoadmin.global_config_url", "URL");
lockPref("autoadmin.append_emailaddr", false/true);
Mvh/
JarrE
David Bienvenu
> On 21.01.2009 21:41, Ben Bucksch wrote:
>> We're currently implementing "autoconfig" for Thunderbird, which is
>> intended to be able to automatically figure out the mail settings
>> needed to configure an email account, like hostnames, ports, SSL
>> on/off, secure auth algo etc.. All that the user should need to
>> provide is his real name, email address and password. We take the
>> domain of the email address and try to find the configuration from that.
>
> Curiosity:
> Is this meant as additional or instead of the existing autoadmin?
not just the prefs to set up initial e-mail accounts. Autoadmin runs
first so that the first account will already be set up, and we shouldn't
get to the new "new account" wizard on startup of a new profile at all.
- David
Dan Mosedale
>
> philor, during review, asked for a "formal security review" by the
> Mozilla Security Group, so that's what this post is about.
Generally, the way Mozilla has been doing those is described at
<https://wiki.mozilla.org/Firefox3.1/Security>. I was hoping to start
driving that process this week, but it looks like I'll start next week.
Your posting is a fine start; thanks for doing the writeup!
Dan
Jan Schejbal
>2) We also contact https://www.<domain>/autoconfig/mail/mozilla.xml
The inserted www. might cause the same security issue as the
autoconfig. thing (although way less probable). So I suggest first
trying https://<domain>/autoconfig/mail/mozilla.xml and then maybe
adding the www.
Jan
--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...
Ben Bucksch
>> 2) We also contact https://www.<domain>/autoconfig/mail/mozilla.xml
>
> The inserted www. might cause the same security issue as the
> autoconfig. thing (although way less probable).
So much less probably that I think it's not happening in practice. If a
hoster hands out addresses underneath hoster.com or customer.com, he'd
be very, very stupid to not have reserved www.hoster.com /
www.customer.com for himself.
> So I suggest first trying https://<domain>/autoconfig/mail/mozilla.xml
> and then maybe adding the www.
That's what Microsoft does (no www). I didn't propose that, because I
don't think we should encourage for a domain to have an "A" DNS record
and a web server running there. Also, the idea of this is to make it
easier to set up than autoconfig.d.com, by just using their normal SSL
web server, which is most likely <https://www.d.com> - I don't think
many companies have a proper SSL cert for <https://d.com>.
Ben
Ben Bucksch
> <https://wiki.mozilla.org/Firefox3.1/Security>. I was hoping to start
> driving that process this week, but it looks like I'll start next
> week. Your posting is a fine start; thanks for doing the writeup!
I posted this myself now
<https://wiki.mozilla.org/Thunderbird:Autoconfiguration:Security_review_FetchConfigFromISP>
Dan Mosedale
Thanks; sorry I haven't yet had a chance to look at this and figure out
next steps. It's high on my list.
Dan