486127 - Seamonkey/Thunderbird send DNS queries when viewing mail, could be used to verify existence of mail accounts

Status: RESOLVED FIXED

(MailNews Core :: Security, defect)

Description

[halfdog]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3

When a mail is viewed in plaintext format, seamonkey will generate DNS requests for every url from the mail text. These DNS queries can be used to find out which spam mails are really viewed.

Please can someone try to reproduce this? I would be shocked if seamonkey gives data to spammers that easily!

Reproducible: Always

Steps to Reproduce:
1. Trace your DNS request, e.g.
tcpdump -i eth0 -nn -vv port 53

2. Send yourself mail:
# nc -vn mailserver 25
(UNKNOWN) mailserver 25 (smtp) open
220 mailserver ESMTP Exim
EHLO localhost
250 OK
MAIL FROM: [e-mail]
250 OK
RCPT TO: [e-mail]
250 Accepted
DATA
354 Enter message, ending with "." on a line by itself
Subject: Test

Test content:
(http://me-at-myhost-net.verifyaddr.org)

.
250 OK id=1LofXY-000120-TW
QUIT



Actual Results:  
15:13:43.506648 IP 192.168.0.1.39340 > 192.168.0.254.53: 32756+ A? me-at-myhost-net.verifyaddr.org. (50)
15:13:43.535984 IP 192.168.0.254.53 > 192.168.0.1.39340: 32756 NXDomain 0/1/0 (113)


Could it be, that such a mechanism is already used in the wild? It seems that I receive more spam mails while I'm online then in the remaining time of the day, but I've never done a statistical test on this hypothesis (so it could be that just more spam-bots are online while I'm online).

Comment 1

[Bruno 'Aqualon' Escherl]

When SeaMonkey creates a DNS request, it asks your local nameserver (usually that from your provider). If the provider doesn't know it, it goes to another level until somewhere the IP to that address is found.

So a spammer only would know that someone read the mail, when he has its own DNS nameserver running, gave your spam mail a unique domain name and no other nameserver in the chain knows that domain already.

In my opinion a very unlikely and not realistic way to get data about spammails.

Comment 2

[Serge Gautherie (:sgautherie)]

halfdog,
Does this happen with Thunderbird too ?

Bruno,
Yet, why is DNS used while viewing a plain-text message ?
Would there be a preference to disable this behavior ?

Comment 3

[Karsten Düsterloh]

I can confirm this for recent trunk, both for SeaMonkey and Thunderbird.
Using tcdump against my local dns server at 192.168.1.1:53 (tcpdump -vvi eth0 host 192.168.1.1 and port 53) when looking at a plaintext message containing the potential url
  http://what.about.sub.domains.in.urls/I.wonder
results in 

18:22:56.493287 IP (tos 0x0, ttl 64, id 32190, offset 0, flags [DF], proto UDP (17), length 75) aupertir.local.40923 > 192.168.1.1.domain: [bad udp cksum e0c2!] 3223+ A? what.about.sub.domains.in.com. (47)

which asks DNS for an IP address (A record) for the domain name what.about.sub.domains.in.urls. Thus spammers and other interested parties can set up their own DNS server and track reading of their spam mails. Given that they can enumerate their spam mails, they can easily track down the corresponding (range of) email addresses.

SeaMonkey 1.1.16 etc. are *not* affected.

Comment 4

[Karsten Düsterloh]

Erm, cut & paste error. :-(
... results in 

18:36:59.719321 IP (tos 0x0, ttl 64, id 45140, offset 0, flags [DF], proto UDP (17), length 76) aupertir.local.47246 > 192.168.1.1.domain: [bad udp cksum df1e!] 8911+ A? what.about.sub.domains.in.urls. (48)

Comment 5

[Karsten Düsterloh]

Seems to be fallout from bug 453403. Setting network.dns.disablePrefetch to true does stop the DNS querying, but turning this off globally is not helpful for SeaMonkey - reading mail should just not force a DNS query, even if using a <browser> element for display...

Comment 6

[Boris Zbarsky [:bzbarsky]]

Does adding:

  <meta http-equiv="x-dns-prefetch-control" content="off">

to the HTML mailnews generates in plain-text mode help?

Comment 7

[Karsten Düsterloh]

(In reply to comment #6)
> Does adding:
> 
>   <meta http-equiv="x-dns-prefetch-control" content="off">
> 
> to the HTML mailnews generates in plain-text mode help?

Yes (at nsMimeHtmlEmitter.cpp#433).

But this doesn't even help against HTML mails with <meta http-equiv="x-dns-prefetch-control" content="on"> in their body(!)...

The idea of DNS prefetching is generally undesirable for mail, imo, since mail is far more privacy-critical than mere browsing.


BTW: I noticed another oddity:
Given dns prefetching is on and a plaintext mail with 

http://what1.about.sub.domains.in.urls/I.wonder
http://what2.about.sub.domains.in.urls/I.wonder
http://what3.about.sub-domains-in-urls.com/I.wonder
http://what4.about.sub.domains.in.urls/I.wonder.html
http://what5.about.sub-domains-in-urls.com/I.wonder.html

I only get dns hits for what1-3, but not for what4-5...

Comment 8

[Boris Zbarsky [:bzbarsky]]

> But this doesn't even help against HTML mails with <meta
> http-equiv="x-dns-prefetch-control" content="on"> in their body(!)...

If it's just HTML mail, that doesn't matter (because it's loading images and such anyway), no?  If it's the "simple html" mode where we block remote image loads, then we should be stripping that out...  For plaintext it's not an issue.

> The idea of DNS prefetching is generally undesirable for mail, imo

I agree; the question is whether we need a change to core Gecko to handle this somehow (with resulting performance costs all around, almost certainly) or whether the existing infrastructure we have can suffice.  If the former, then we need a core bug with some blocking1.9.1 flags on it.

Comment 9

[Karsten Düsterloh]

(In reply to comment #8)
> If it's just HTML mail, that doesn't matter (because it's loading images and
> such anyway), no?

I can turn off loading remote content via mailnews.message_display.disable_remote_image - but this has no influence on dns prefetching. I currently can't turn off dns prefetching for mail alone.

> If it's the "simple html" mode where we block remote image
> loads, then we should be stripping that out...

Yes, dns prefetching occurs for both original HTML and simple HTML.

> For plaintext it's not an issue.

True, given the <meta>.
(And, at least, the network.dns.disablePrefetch has priority over the <meta>.)

Comment 10

[Boris Zbarsky [:bzbarsky]]

> mailnews.message_display.disable_remote_image 

Ah, we have a separate setting for that from the "Simple HTML" setting?  OK.

If the existing <meta> setup doesn't work for you, then we need more core infrastructure here; I believe that right now the only times we avoid preloading is from https: pages and via the <meta> tag.  We could either add docshell type checks here or change the check for https to treat mail as a "secure" context or various other things... but we need a bug tracking it and blocking 1.9.1 so we make sure it actually happens.

Comment 11

[David Ascher (:davida)]

bienvenu feels it's a blocker.  Can someone who understands the Core bug file it and nominate it for 1.9.1?

Comment 12

[David :Bienvenu]

Thunderbird might be able to get away with setting network.dns.disablePrefetch

Comment 13

[Karsten Düsterloh]

Filed bug 492196.

Comment 14

[Boris Zbarsky [:bzbarsky]]

OK, the change I made in bug 492196 makes DNS prefetch default to off in TYPE_MAIL and TYPE_EDITOR docshells.  It's now configurable for all docshells, with child shells inheriting the parent shell value by default.  Someone with more mailnews clue than I should check what else remains to be done here for SM and tbird.

Comment 15

[Karsten Düsterloh]

Looks good - I couldn't reproduce with any of my testcases.

Comment 16

[David Ascher (:davida)]

Is this all fixed?

Comment 17

[Dan Mosedale (:dmosedale, :dmose)]

My recollection of the APP_TYPE_MAIL stuff is that it applies to all docshells in the mail window, which means that while the security bug should be fixed, it has come at a cost of turning off DNS prefetching in web content tabs as well.  Resetting this bug to UNCONFIRMED, as we should have someone verify that.

Whether or not that's the case, my reading is that bz's patch should have made the privacy issue go away, so I think this bug wants to be resolved as a DUP of bug 492196.  If my understanding is correct, we also want a new bug to be filed about the DNS prefetching in web content tabs in Thunderbird.

bz/Standard8, can you confirm or deny my understanding?

Comment 18

[Boris Zbarsky [:bzbarsky]]

> My recollection of the APP_TYPE_MAIL stuff is that it applies to all docshells
> in the mail window

That recollection is incorrect.  The APP_TYPE_* stuff is not inherited; it only applies to the docshell it was explicitly set for.

Now the DNS prefetch value _is_ inherited, so any descendants of an APP_TYPE_MAIL docshell will default to having it off per bug 492196.  I don't know which docshell in mail has the APP_TYPE_MAIL set, offhand.

Comment 19

[Magnus Melin [:mkmelin]]

So can we mark this fixed, and get a new bug for enabling dns prefetching in thunderbird web content, if needed?

Comment 20

[Mark Banner (:standard8)]

The additional fixes done in bug 544745 now mean this is fixed as well (and there are test cases confirming the fix).