203940 - block more remote protocol types, when user block remote images in mail messages

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[(not reading, please use [e-mail] instead)]

look at mozilla/extensions/cookie/nsImgManager.cpp

the current code will allow <img src="gopher://"> images to be shown,
assuming gopher doesn't require a username/password.  (bug #51631? will deny any
thing requiring a password prompt)

alternatively, we could do this:

// whitelist
if (chrome, resource, file (for editor, msg compose), mail related)
  return;

// everything else, black list
else (http, https, ftp, gopher, etc)
  if ((a mail message) && (mBlock || ftp))
    block

Comment 1

[Boris Zbarsky [:bzbarsky]]

For that matter, what about file:// ?  Are we relying on CheckLoadURI to prevent
people sending mail that randomly opens up crap off your hard drive?

Comment 2

[(not reading, please use [e-mail] instead)]

datapoint,

 we had a bug (back in 4.x?) where a message (or webpage?) would tell you:

"hey, I hacked your computer, here's your autoexec.bat", and they did
file://C|/autoexec.bat"

so it wasn't real, but users were confused.

Comment 3

[[e-mail]]

just as a note here:

bug 22994 has a fix for blocking cookies in mailnews. there are some holes in
the algo that cookies used, so that fix will be landing for 1.4b.

we may want to ponder porting this stuff into nsImgManager::ShouldLoad at some
point.

Comment 4

[Jerry Baker]

Why not something more along the lines of:

if ([exhaustive list of local protocols])
  return early;
else // not specifying any protocols here. Just saying if
     // it's not in our list of local protocols.
  if ((a mail message) && (mBlock || ftp))
    block

Comment 5

[Boris Zbarsky [:bzbarsky]]

Define "local protocols" given that Mozilla embeddors can add implementations of
arbitrary protocols (eg data:, view-source:, about:, etc, etc).

Comment 6

[Boris Zbarsky [:bzbarsky]]

But yes, I think we want to white-list here....

Comment 7

[Jerry Baker]

I think a simpler remedy might be to make it so that images loaded by any
protocol are considered remote. That way only images that are actually
physically attached to the message will be displayed. That is the behavior that
I imagined was happening all the while anyway.

Comment 8

[Boris Zbarsky [:bzbarsky]]

You seem to have a fundamental misunderstanding of how images that are attached
to the mail work.  They are also loaded via a protocol handler (imap:// or the
like).

Comment 9

[Jerry Baker]

No need to get snippy. When you open a message from an IMAP folder, is the
entire message body not downloaded at the same time? I was under the impression
that it would be since attached images are part of the message body.

Comment 10

[mozilla]

I would take it one step further. When I select "block remote pictures from
mail", I expect it to NEVER issue HTTP requests to remote servers due to email
borne HTML. This is an importnat privacy issue, as I don't want to be tracked
for when I read my mail.

I just got a spam that violated this expectation of mine. It contained the
following snippet:
              <embed src="http://211.104.119.200/event/hp.swf" quality="high"
pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash" width="600" height="150"></embed></OBJECT>

The remote site was contacted, and the media was downloaded. This happened to me
on the Debian/Sid version of 1.3.

I would change "Platform" to "all", and severity to "critical". At least to me,
this appears to be a security problem.

Comment 11

[Matthias Versen [:Matti]]

That is no image loaded with another protocol, that is a shockwave flash applet.
(=that is not this bug)

Comment 12

[mozilla]

My beef is with the very fact that remote media is fetched when I asked Mozilla
not to. I could care less what that media is.

As far as I'm concerned, this bug should be "block all remote protocol types,
when user block remote images in mail messages".

If you think opening a new bug for it is justified, I'll do it. I will then
think that this bug is encapsulated in that one.

Comment 13

[Michiel van Leeuwen (email: mvl+moz@)]

No, it shouldn't. This is a very specific bug about a specific part of the code.
You are looking for bug 28327. You should not try to morph bugs.

Comment 14

[(not reading, please use [e-mail] instead)]

another data point:

a way around the "block remote images" is to use news.  (you might not have
gopher, but the mozilla suite has news).

like

<img src="news://host:port/messageid?part=1.2&filename=foo.jpeg">

that will work today.

I'm a behind in reading all the comments, but I'm sure once I do, I'll agree
with bz's comment about whitelisting.

Comment 15

[(not reading, please use [e-mail] instead)]

scott has a content policy manager for tbird now, so he'll want this too.

Comment 16

[Michiel van Leeuwen (email: mvl+moz@)]

What are the protocols we should put in the whitelist?
This is what i think: chrome, resource, mailbox, about and file. Anything
missing in that list?

Comment 17

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420