278176 - Remote server hits reading mail possible using news: (gopher no longer a problem)

Status: NEW

(Thunderbird :: Security, defect)

Description

[Daniel Veditz [:dveditz]]

Spun off to address bug 28327 comment 307 (307!!). Sub-document loads are
finally blocked, but the code in nsMsgContentPolicy.cpp kicks in only for http,
https and ftp loads. Server hits are still possible using other protocols like
gopher: (found in the wild) and news:.

In practice external protocol handlers like gopher: will now bring up a
confirmation dialog so for the most part those will be safe since a user could
cancel them (the dialog might be turned off, per protocol, by a few users).
news:, however, is internally supported so that could still be used.

The code should be turned around to whitelist only the expected and safe mail
protocols, check settings for http/https, and everything else should be blocked
 as ftp is.

News:, ftp: and other protocols should still be allowed for explicit link
clicks. I think that's not a problem, but since news: is an exposed protocol I'm
not sure if the same content-limiting logic will kick in.

Comment 1

[Asa Dotzler [:asa]]

darin, do we need a new and more broadly applicable solution or can we do
something similar for more protocols.

Comment 2

[Scott MacGregor]

Dan, when we tested this a while ago, all that happened was an external url
dialog came up if you tried to do:

<img src="gopher://....>

when you read the message

so there still wasn't a privacy issue unless you clicked ok on that dialog.

Its unclear to me if this privacy issue (which I claim isn't a full privacy
issue because that dialog comes up even though that's not intended) should be
part of the security respin of 1.0?

I'd like to make this a 1.1 blocker if possible....

Comment 3

[Daniel Veditz [:dveditz]]

The gopher dialog *is* intended, to get the user's permission before running
external protocol handlers. Some small fraction of users who actually use gopher
may turn off the dialog, but most people would be immune as noted in comment 0.

My main concern is the news: protocol. That's internal to Thunderbird and would
not trigger the confirmation dialog.

Comment 4

[Scott MacGregor]

Attachment: improved content policy manager for loads

This doesn't fix the news URL case yet, but it fixes problems with non exposed
url schemes like gopher, ftp, etc.

Here's the new policy:

1) If the requestion location is chrome, resource or about allow all loads

For everything else:
2) If the content location being loaded is an exposed protocol (imap, news,
pop3, addrbook, mailbox, etc.) OR if content location is a chrome URL (like
messageBody.css), then allow the load.

For everything else:
3) If the content location is http or https, then fall into the exiting show
remote content policy code to determine what to do. 

Otherwise, it gets denied.

Now when I view a message that has something like:

<img src="gopher://foobar.com">, I don't get the "Launch External Protocol"
dialog when I view the message. 

Still haven't figured out how to modify the new policy to handle news yet. 

Hopefully this won't break too much for odd things like imap parts on demand,
downloading the rest of a pop3 message, etc. :)

Comment 5

[Scott MacGregor]

ok this patch has been checked into the trunk for testing before we talk about
it for 1.0.1.

I will leave this bug open since this doesn't address the news case yet. I'm
still not sure what to do for that case yet. 

Comment 6

[Scott MacGregor]

so far this patch has tested out ok on the trunk so I just checked it into the
1.0.1 branch.

That leaves ust deciding what to do about the news issue before putting a fork
in this bug. 

Comment 7

[Scott MacGregor]

I tested this by creating a new message and inserting an image src like:

<img src="http://mozilla.org/mozilla.gif">

Then storing this file in a local folder. Find that folder in your profile and
edit the file for the folder. Now change the src url to something like:

<img src="gopher://foo.com">

Save the file and run thunderbird 1.0. click on the message. You should see a
dialog about launching a gopher URL.

Run it again using 1.0.1. You should not see the dialog anymore. We completely
ignore the gopher url. 

Note: you have to fix the URL by hand in the mail folder because we won't allow
a user to send a message that uses an external protocol like gopher as an img
src URL.

Comment 8

[sairuh (rarely reading bugmail)]

this works as described in comment 7. verified fixed using 2005030802-1.0.1
tbird bits on mac os x 10.3.8.

Comment 9

[Tracy Walker [:tracy]]

looks good on windows 2005-03-09-09-aviary1.0.1

Comment 10

[Scott MacGregor]

this has been ported to the AVIARY_1_0_20040515_BRANCH. This does not mean that
it was actually fixed in the 1.0 release of course.

Comment 11

[Asa Dotzler [:asa]]

Is this still a problem on the trunk? If not, can you unset the blocking1.1+
flag? Thanks.

Comment 12

[Scott MacGregor]

moving the remaining issue for this to 2.0

Comment 13

[timeless]

Comment on attachment 175596 [details] [diff] [review]
improved content policy manager for loads

>+    // if aContentLocation is a protocol we handle (imap, pop3, mailbox, etc) or is a chrome url, then allowe the load

please spell 'allow' correctly...

Comment 14

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I'm not sure if I'm the best person to ask nor if this is a good question to ask, but is this bug still an issue with Shredder trunk nightlies?

Comment 15

[Dan Mosedale (:dmosedale, :dmose)]

Unless some other bug has changed that code, I assume it would be.  The way to test would be to post an HTML news message with an <img> tag that points to something on a webserver, and then try and read that message and see if the image shows up without any sort of prompting.

Comment 16

[David :Bienvenu]

Mark, do you think this is still an issue?

Comment 17

[Mark Banner (:standard8)]

I've just done some testing with this url in the src of an img:

news://news.bu.edu:119/SAb5r.107247%242a.73043%40en-nntp-14.dc1.easynews.com?group=alt.binaries.birds&key=36067&part=1.2&type=image/jpeg&filename=tern.JPG

The image loaded for local email, and for saved email, so I believe this is still an issue.