544745 - (CVE-2009-4629) DNS Prefetch security issue: Information leak

Status: RESOLVED FIXED

(Thunderbird :: Security, defect)

Description

[julien.t43+mozilla]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1

see https://secure.grepular.com/DNS_Prefetch_Exposure_on_Thunderbird_and_Webmail
Already discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=492196

I'm not sure, but about:config has 'network.prefetch-next' (true by default), setting to false could help.
I didn't find 'network.dns.disablePrefetch' in about:config, maybe js parameter.

Depending on comments, it could be a wise choice to set default option to another value.
I think, in most case, an url link will be open by an external browser so I'm not sure what is the usage of dns prefetch here.
Another option, would be disabling prefetch when using text mode or encrypted access like gmail does or maybe have a 'paranoid' button in preferences ...





Reproducible: Always

Comment 1

[Jo Hermans]

see bug 486127 - it's supposed to be disabled in TYPE_MAIL and TYPE_EDITOR docshells. I'm not sure if it's disabled when you see HTML-mail (which will use network.dns.disablePrefetch I think)

Comment 2

[julien.t43+mozilla]

Thanks, I have not found this one.
But if I understand correctly TYPE_MAIL/TYPE_EDITOR are used when writing an email, right ?
what about viewing ? as text or simple web mode, which are seen as more "secure" ?

In my opinion, at least, writing email or viewing as text and simple html need to avoid prefetch.

The blog article says this issue is still valid for 3.0.1.

Comment 3

[Mike Cardwell]

I'm the person who wrote that blog item. I have confirmed that adding the following item to about:config in Thunderbird stops the pre-fetching from taking place:

network.dns.disablePrefetch=true

I'd suggest that the next version of Thunderbird 3 comes with this option enabled.

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to comment #3)
> I'm the person who wrote that blog item. I have confirmed that adding the
> following item to about:config in Thunderbird stops the pre-fetching from
> taking place:
> 
> network.dns.disablePrefetch=true
> 
> I'd suggest that the next version of Thunderbird 3 comes with this option
> enabled.

Mike would you like to provide a patch ?

Comment 5

[Mike Cardwell]

I don't have an environment set up to test with but as far as I can see, the patch would be as simple as this:

--- comm-central/mozilla/modules/libpref/src/init/all.js.ORIG   2010-02-08 14:38:16.000000000 +0000
+++ comm-central/mozilla/modules/libpref/src/init/all.js        2010-02-08 14:39:23.000000000 +0000
@@ -803,6 +803,8 @@
 // enables the prefetch service (i.e., prefetching of <link rel="next"> URLs).
 pref("network.prefetch-next", true);

+// Disable DNS pre-fetching for privacy reasons
+pref("network.dns.disablePrefetch", true);

 // The following prefs pertain to the negotiate-auth extension (see bug 17578),
 // which provides transparent Kerberos or NTLM authentication using the SPNEGO

Comment 6

[Owen Marshall (Not reading bugmail)]

Hold on... Simply changing that pref would just mask the underlying problem. 

IIRC APP_TYPE_MAIL applies to viewing messages. If it doesn't, I think we need to set that instead.

Investigating.

Comment 7

[Boris Zbarsky [:bzbarsky]]

> IIRC APP_TYPE_MAIL applies to viewing messages.

That was my understanding too.  If it does not we have _much_ bigger problems than DNS prefetch.

Comment 8

[Owen Marshall (Not reading bugmail)]

Wireshark indicates DNS lookups for any mail message with a link, in both HTML mode and plain text.

Confirmed on both Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100208 Lanikai/3.1b1pre *and* Thunderbird 3.0.1 release.

This was a 1.9.1 blocker, so I'm requesting blocking Thunderbird 3.1.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

It would be interesting to know if this is a regression from Thunderbird 2.  Is it?

These days, APP_TYPE_MAIL isn't really used in Thunderbird, from what I can see.  Instead, we try and figure out which loads are message loads instead of inferring a lot from which docshell the load is happening in.  

Boris, can you elaborate on what you meant with comment 7?

At this point, knowing what I know now, I suspect we would hold Thunderbird 3.1 if this were the last bug standing.  However, that does depend somewhat on whether it was a regression from Tb2 and how much work it is to fix.

Comment 10

[Dan Mosedale (:dmosedale, :dmose)]

For the interested reader, the Thunderbird content policy code lives at <http://mxr.mozilla.org/comm-central/source/mailnews/base/src/nsMsgContentPolicy.cpp>.

Comment 11

[Boris Zbarsky [:bzbarsky]]

> It would be interesting to know if this is a regression from Thunderbird 2

Thunderbird 2 is based on a Gecko version that did not have DNS prefetching.  So yes.

> Boris, can you elaborate on what you meant with comment 7?

Hmm.  I thought we used this in more places.  Right now, APP_TYPE_MAIL is used in the following places in Gecko:

1)  Controlling access to the window.opener of a window: if the opener is
    APP_TYPE_MAIL we hand back null instead of the real opener.  This fixes bug
    105050.
2)  Controlling DNS prefetching.

I'm just as happy if you want to move to some other setup for the DNS prefetching (e.g. explicitly telling that docshell to not prefetch).  Not sure what you want to do about 105050.  I definitely think you guys need some regression tests here...

If we really don't need APP_TYPE_MAIL (or do we for Seamonkey?), that would be very nice, of course!

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, and the point is that DNS prefetch does not make content policy calls, because it really doesn't fit within the content policy API (e.g. there may be no URI available).

Comment 13

[Dan Mosedale (:dmosedale, :dmose)]

Turning Henrik's regression test from bug 105050 into something automated (a MozMill test, I suspect) as part of fixing this bug sounds like a good idea.

My current suspicion is that much of the logic encapsulated in nsMsgContentPolicy::ShouldLoad and its callees is identical to the logic that wants to be used to decide if we allow both window.opener and DNS prefetching.  It's almost as though we should hoist much of that logic out of ShouldLoad into one or more tightly-defined sub-APIs and then call those APIs both from ShouldLoad and from Gecko's DNS prefetching code and window.opener vetting code.

SeaMonkey does need APP_TYPE_MAIL as the code is written today, (look towards the top of ShouldLoad to see at least one usage).

Another thing we could consider would be to get rid of APP_TYPE_MAIL entirely, and replace it with a somewhat different concept: URI_TYPE_MAIL, perhaps...

Comment 14

[Mark Banner (:standard8)]

I'm going to dig into this tomorrow to try and figure out what why DNS prefetch isn't being disabled.

Comment 15

[Mark Banner (:standard8)]

I've just been doing some investigations on the trunk builds. Here's what I've found so far:

- The docshell tree is created before APP_TYPE_MAIL is set on the root docshell.

APP_TYPE_MAIL being set currently happens in InitMsgWindow:

http://hg.mozilla.org/comm-central/file/388ec73d6f39/mail/base/content/mailWindow.js#l140

which is called from, or soon after the onload hander function.

This appears to be a long time after the docshells have been created.

- As a result, the child docshells created on startup don't have DNS prefetch disabled.
- The root docshell gets DNS prefetch disabled when APP_TYPE_MAIL is set.

The inheritance option is verified if you create a new content tab - i.e. a new browser element within the same window. The docshell for the new browser element gets the DNS prefetch disabled.


In Gecko 1.9.2/1.9.3, the docshell has an allowDNSPrefetch attribute. So we can do the following:

- mailnews sets allowDNSPrefetch to false on the docshells for elements where it will display messages/compose emails (for instance, we already set allowAuth to false on the messagepane docshell).

- We drop the APP_TYPE_MAIL inheritance from core, allowing contentTabs to use DNS prefetch.

In Gecko 1.9.1 (TB 3 builds), we don't have the allowDNSPrefetch attribute. Possible options:

1) Move the setting of APP_TYPE_MAIL to before the docshells are set up.

2) Alter core so that setting APP_TYPE_MAIL will pass the allowDNSPrefetch attribute down the docshell tree.

I think option 1 may not easily be possible, but I'd like to see if Boris has any thoughts on either of these or other options.

Comment 16

[Karsten Düsterloh]

Do you have any idea why my Linux 64 bit SeaMonkey debug builds won't show the problem? Your analysis doesn't seem to leave room for timing issues and such, so I wonder what's wrong at my end...

Comment 17

[Mark Banner (:standard8)]

(In reply to comment #16)
> Do you have any idea why my Linux 64 bit SeaMonkey debug builds won't show the
> problem? Your analysis doesn't seem to leave room for timing issues and such,
> so I wonder what's wrong at my end...

Well I just downloaded SM Mac and checked the docshell on the messagepane browser and it has allowDNSPrefetch set to true.

So I guess there could be a 32-bit versus 64-bit issue (which I doubt), or we could have some weird timing issue. I've got SM building with my little bit of debug, so hopefully that will give us more info.


And whilst I'm here, the same issue exists in the compose window as well afaict.

Comment 18

[Boris Zbarsky [:bzbarsky]]

> In Gecko 1.9.1 (TB 3 builds), we don't have the allowDNSPrefetch attribute.

Sure you do.  It's right here: http://mxr.mozilla.org/mozilla1.9.1/source/docshell/base/nsIDocShell.idl#542

Comment 19

[Mark Banner (:standard8)]

Attachment: The fix

Here's the fix for trunk and 1.9.2 based builds. 1.9.1 has a different interface so I just need to tweak things slightly.

Comment 20

[Mark Banner (:standard8)]

Comment on attachment 426246 [details] [diff] [review]
The fix

I've just seen Neil's suggestion for a better place for disabling DNS prefetching in editor/ and I've also realised I forgot to add a test for the standalone message window.

Comment 21

[Mark Banner (:standard8)]

Attachment: The fix v2

Revised patch. This includes disabling DNS prefetch in a central location for compose and composer windows (which also fixes it for SeaMonkey) and I ported the 3-pane/message window part of the patch to SeaMonkey as well.

The test also now includes checks in the standalone message window.

Neil, can you sr the editor and suite parts? I'm looking to get this in before end of Friday to meet our 3.0.2 code freeze.

Comment 22

[Mark Banner (:standard8)]

Attachment: The fix v2 - comm-1.9.1 version

David, this is the 1.9.1 version of the patch - can you give it a quick check over please.

Comment 23

[David :Bienvenu]

Comment on attachment 426487 [details] [diff] [review]
The fix v2

+  addMsgToFolder(folder);
+
+  // Now we've got a message selected, check again.
+  if (mc.e("messagepane").docShell.allowDNSPrefetch)
+    throw new Error("DNS Prefetch on messagepane is not disabled at startup");

probably want to change the throw text to refer to having a message selected. Same thing for test_dnsPrefetch_standaloneMessage()

The copyright notice was copied from an other file - I leave it to you to decide if the attribution is still accurate :-)

Comment 24

[David :Bienvenu]

Comment on attachment 426491 [details] [diff] [review]
The fix v2 - comm-1.9.1 version

modulo previous nits.

Comment 25

[Mark Banner (:standard8)]

Checked in: http://hg.mozilla.org/comm-central/rev/6bc47ea91828

Comment 26

[Mark Banner (:standard8)]

Comment on attachment 426491 [details] [diff] [review]
The fix v2 - comm-1.9.1 version

a=Standard8, this is a low/medium risk with tests but of high value to users.

Comment 27

[Mark Banner (:standard8)]

Checked into 1.9.1:
http://hg.mozilla.org/releases/comm-1.9.1/rev/109a228e59ab

This will be in the 3.0.2pre builds from tomorrow.