126082 - Don't show some content types inline

Status: VERIFIED FIXED

(MailNews Core :: MIME, enhancement)

Description

[Ben Bucksch (:BenB)]

Followup of bug 119266.

Allow user to disable the display of some (possibly insecure) content types
inline. This is important to guard against buffer overflows in hardly-needed
code parts (e.g. the sun attachment decoder, the richtext decoder or the image
lib) and against bug 126008 and similar ones in combination with bug 108153 /
bug 30888.

The user can still see and access these parts via the attachment pane. (Either
via the default handler or using saveas and an external app or by temporarily
allowing them to display inline.)

This is different from bug 55657 (View attachments inline), because this bug
decides based on the content type and not on attachment or not. For example,
richtext might appear in the body, but it might not be desired to show up
inline, while HTML attachments are fine to display inline (after having been
sanitized). This bug is mainly about security.

Patches will probably be attached to bug 30888, because
- the patch for that bug is not yet checked in
- this bug touched the same code parts
- that bug makes not much sense without this one.

Comment 1

[Ben Bucksch (:BenB)]

See <http://bugzilla.mozilla.org/show_bug.cgi?id=119266#c16>.

My current thinking is:
We could add a pref which specifies a blacklist of content types which are to be
displayed as plaintext or as "external attachment" (shown in the attachments box
only). This is some work, because I'd have to parse that comma-separated list.

Alternatively, I could hardcode the external content type handlers that are
built with Mozilla and are considered insecure (e.g. vcard). I don't think it's
as bad as it sounds, because those are which ship with Mozilla and which we know
about and have to take responsibility for. If the user installs any additional
external content type handlers, he does it at his own risk.
This approach would have the advantage that we could dis-/enable vcards in the
UI (important for bug 108153) without the risk of overwriting the user's
blacklist pref.

I think IÄll go with the latter approach. Unless somebody has another idea...

Comment 2

[Ben Bucksch (:BenB)]

> Alternatively, I could hardcode the external content type handlers that are
> built with Mozilla and are considered insecure (e.g. vcard).

That would look like (pseudo-code):

if ((tempClass = mime_locate_external_content_handler(content_type,
&ctHandlerInfo)) != NULL)
{
   if (attachment_inline > 0
       && (content_type == "text/vcard" ||
           content_type == "text/calendar")
         /* if the user doesn't like inline attachments and
            we matched against one of the known plugins (built with Mozilla)
            which display uncommon content types inline... */
     clazz == mimeExternalObjectClass; // treat as non-inline attachment
   else
     clazz = (MimeObjectClass *)tempClass; // allow handler plugin
}
else

Comment 3

[georgi - hopefully not receiving bugspam]

This sounds quite reasonable to me.

Instead of "black list" I suggest everything except "text/plain" plus some hard
coded "multipart/*" to be displayed as attachment and a "good list" in the
preferences which may be displayed inline .

Isn't this quite similar to bug 119266?

Comment 4

[Ben Bucksch (:BenB)]

Fix checked into trunk.

Please test the feature and try to circumvent it, i.e. get arbitary HTML
rendered although the new options are active. If so, please file a new bug
against Mailnews/MIME, owner me, and mention it here.

Some documentation can be found at <http://www.beonex.com/temp/index.html>. When
I have ftp access to my private server again, I will move it to
<http://www.bucksch.com/1/projects/mozilla/108153>.

Comment 5

[Ben Bucksch (:BenB)]

.

Comment 6

[Trix Supremo]

verified on trunk build 2002071008-trunk