119266 - Option to disable all active content in mail

Status: VERIFIED DUPLICATE of bug 30888

(MailNews Core :: Security, defect)

Description

[Mitchell Stoltz (not reading bugmail)]

There's probably another bug on this somewhere, but for sake of clarity I'm
putting this in a new bug. The patch to follow was written by Georgi Guninski.
Review and feedback would be appreciated.

Comment 1

[Mitchell Stoltz (not reading bugmail)]

Attachment: Patch part 1

Comment 2

[Mitchell Stoltz (not reading bugmail)]

Attachment: Patch part 2

Comment 3

[Håkan Waara]

Am I correct in my understanding that this bug is for being able to disable 
email attachments?

If so, is this bug 55657's backend? I'm sure I can help out to implement the 
front-end if you want (i.e. fix that bug), if you make this stuff depend on 
some pref.

Comment 4

[Håkan Waara]

BTW, if you can make depend on a pref, use |mail.inline_attachments| (which is 
already used in NS4.x IIRC).

Comment 5

[georgi - hopefully not receiving bugspam]

The idea of this patch is to disable automatically previewing of HTML email
unless the user explicitly wish to do so.
HTML mail may contain active content - scripts, <iframe>s, etc.
If an exploit pops up users may be exploited by email or forced to visit a web page.
NIMDA made quite the noise on outlook.
Besides HTML mail has privacy implications - web bugs, tracking the opening or
not opening of a message thru content on third party servers, probably more.
Some people really do not want to receive text/html mail only.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

*** Bug 119673 has been marked as a duplicate of this bug. ***

Comment 7

[Ben Bucksch (:BenB)]

Related bugs:
Bug 30888 is about showing only plaintext.
Bug 18427 is about santiyzing HTML to only stuctural markup.
Bug 28327 is about querying external servers.
Bug 22994 is about cookies.
The pref would be a nice addition to bug 31907.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Thanks for the related bug references, but please do not dupe this bug. Let's
keep this bug focused on Georgi's patch and not get lost discussing related
feature requests.

Comment 9

[Jean-Francois Ducarroz]

Comment on attachment 64355 [details] [diff] [review]
Patch part 1

This patch doesn't compile on window because of snprintf which is not defined.
Instead use PR_snprintf but you must first include "prprf.h". Please replace
strcpy by PR_strcpy.

I don't think printing a link to the part inside the message body is the right
thing to do. Rather, you should  show those part as attachment in the chrome
(like we do with any other attachment). Or at list you should draw a nice
attachment box like we did in 4.x

Comment 10

[Jean-Francois Ducarroz]

Comment on attachment 64356 [details] [diff] [review]
Patch part 2

first couple syntax comment:
- preff should be pref
- some indentsation inconsistence

I tried the patch and it doesn't work well all the time:
I have a multipart/related message, the first part is text/html and the second
one is image/gif. When I click on the link to the part (the first one), this
one is shown empty!

ALso, we should cache the pref of at least the pref service to avoid getting it
all the time but this is a generic problem of mime!

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Attachment: New patch, part 1

Comment 12

[Mitchell Stoltz (not reading bugmail)]

Attachment: New patch, part 2

Comment 13

[Ben Bucksch (:BenB)]

With bug 30888 having a patch, does this still make sense? Bug 30888 scatches
the same itch and gives IMO a nicer UI (no additional clicks needed). If there
is no plaintext part, bug 30888 allows to still read the mail safely, while this
bug requires the curious user to view the mail as (interpreted) HTML.

Comment 14

[Ben Bucksch (:BenB)]

> while this bug requires the curious user to view the mail as (interpreted) HTML.

Or not at all, if I saw that correctly?

Comment 15

[Judson Valeski]

Should this be more generically tied in? See nsIWebBrowserSetup and
http://bugzilla.mozilla.org/show_bug.cgi?id=125168

Comment 16

[Ben Bucksch (:BenB)]

Part 1 is interesting (and does not overlap with bug 30888 / bug 108153). Here,
Georgi Guninski lets, after a content type handler has been chosen, through only
the content type handlers that he explicitly likes. This guards against e.g.
loopholes in our vcard handler (see bug 126008).

However, it also completely breaks the libmime extension mechanism, which is 
designed to allow e.g. a third-party PGP plugin to register itself and handle
certain content types. If the user has a PGP plugin installed, we should assume
that he wants to use it (even users of these paranoid prefs). But vcard is also
an external handler.

I see no good solution other than
- not installing insecure external handlers.
  This breaks the runtime-configurability.
- hardcoding "nice" and "unsafe" external handlers
  This appraoch is also kind of broken, because the point of external handlers
  is that we don't know (most of) them yet.

Any ideas?

Comment 17

[Ben Bucksch (:BenB)]

I filed bug 126082 for my own patches about this problem, because mstoltz asked
to "keep this bug focused on Georgi's patch".

Comment 18

[georgi - hopefully not receiving bugspam]

Ben,

I am not a mail guru and don't know mime internals.
The idea of the patch was to allow only known good content and reject everything
else.
Could please give me a pointer to "external handlers", I am not familiar with them.
I am little confused that *both* vcard and pgp plugin are external handlers.
I definitely don't want vcards displayed inline and the vcard code is in the
mozilla tree so I don't see any external.
On the other hand if I chose to put a shared library which interferes with
Mozilla so it's entire my choice to trust it, so a possible solution would be to
give access to shared libraries installed explicitly by the user to display
inline content?

Comment 19

[Ben Bucksch (:BenB)]

Georgi, I understand your general idea, and it made me "find" bug 126008.

> Could please give me a pointer to "external handlers", I am not familiar with
> them.

<http://www.mozilla.org/mailnews/libmime-content-type-handlers.html>

<quote
src="http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimei.cpp#305">
305 if ((tempClass = mime_locate_external_content_handler(content_type,
&ctHandlerInfo)) != NULL)
306 {
307   clazz = (MimeObjectClass *)tempClass;
308 }
309 else
310 {
</quote>

The vcard handler code lives in mailnews/mime/cthandlers/vcard/mimevcrd.*.

We may also want to avoid the calendar plugin in mailnews/mime/cthandlers/.

> I definitely don't want vcards displayed inline and the vcard code is in the
> mozilla tree so I don't see any external.

The "external" is a term by me. It's a "Content Type Handler Plugin", the same
way a PGP handler might be a plugin. I.e. it is not hardcoded into mimei.cpp and
not part of libmime.so, but lives in its own lib (libvcard.so). So, it only
happens to be built and installed by default with Mozilla, but is otherwise no
different than a possible PGP plugin by NAI, which is installed with PGP, not
with Mozilla.

> On the other hand if I chose to put a shared library which interferes with
> Mozilla so it's entire my choice to trust it
> so a possible solution would be to give access to shared libraries installed
> explicitly by the user to display inline content?

Yes, I think so, too, see bug 126082.
(OTOH, it's also "your choice to trust" Mozilla's handlers :-) .)

Comment 20

[Ben Bucksch (:BenB)]

Bug 30888 and bug 126082 are fixed on the trunk, see
<http://www.beonex.com/temp/index.html> /
<http://www.bucksch.com/1/projects/mozilla/108153> for docs.

Is there anything left to be done in this bug (I don't quite understand part 2
attached here)?

(If you have any other comments, feel free to mail me about that, too.)

Comment 21

[Mitchell Stoltz (not reading bugmail)]

Ben, what's the status of this? Is it going to make Moz1.0?

Comment 22

[Ben Bucksch (:BenB)]

I don't know, see my last comment in bug 30888.

Comment 23

[Mitchell Stoltz (not reading bugmail)]

Since Ben's patch in 30888 has gone in, can this bug be closed? Or is there
additional functionality here that someone whats?

Comment 24

[Mitchell Stoltz (not reading bugmail)]

*** This bug has been marked as a duplicate of 30888 ***

Comment 25

[John Unruh]

V