191928 - Make mime class whitelist optionally even more strict (ultra-paranoid mode :-) )

Status: RESOLVED WONTFIX

(MailNews Core :: MIME, enhancement)

Description

[Ben Bucksch (:BenB)]

Filing bug on behalf of Georgi Guninski, who wrote in bug 30888 comment 201:

> Ben,
>
> What adding another options which further restricts the classes which are
> allowed?
>
> In PRBool mime_is_allowed_class(const MimeObjectClass *clazz,...
> I am concerned about the following:
> clazz == (MimeObjectClass *)&mimeMultipartAppleDoubleClass ||
> clazz == (MimeObjectClass *)&mimeMessageClass ||
> clazz == (MimeObjectClass *)&mimeInlineTextHTMLSanitizedClass ||
> clazz == (MimeObjectClass *)&mimeInlineTextHTMLAsPlaintextClass ||
> Especially AppleDouble class - isn't it kind.
>
> Compatibility with existing behavior will still be maintained.

I personally certainly don't have any objections.

Question is, if it makes sense. See code and comment following "if
(allow_only_vanilla_classes)"
<http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimei.cpp#304>.

Going through your list:

  mimeInlineTextHTMLSanitizedClass, mimeInlineTextHTMLAsPlaintextClass

I wrote the following code comment to that:
/* The latter 2 classes bear some risk, because they use the Gecko
   HTML parser, but the user has the option to make an explicit
   choice in this case, via html_as. */
I am not sure what exactly I meant which this comment :-(, but IIRC, I came up
with a combination of settings that never use these 2 classes. IIRC,
types_of_classes == 100, html_as = allow html - html will be disallowed by the
whitelist types_of_classes == 100, and the sanitizer and asplaintext classes
won't be used by html_as = allow html, so neither real HTML nor sanitizer nor
asplaintext will then be used. I think, it then falls back to the external
class, meaning that the HTML part shows up as attachment. I am not sure, please
confirm with the code and testing before relying on it.

  mimeMultipartAppleDoubleClass

IIRC, ducarroz arrused me that the class is both quite useful when communicating
with Mac users as well as pretty safe. Your mileage may vary. It's questionable,
if it's worth to add a new option for that. I don't have anything against it,
though.

  mimeMessageClass

This should be fairly safe, it should only trigger code that's triggered anyways
wehn displaying a message. The only new thing would be the light grey HTML
header box (instead of the middle grey XUL header bar), if there happened to be
an overflow, but that's only 3 fields or so, I think, (Date, Subject, Sender),
so it should be easy for you to verify it as safe or find a bad bug ;-).


In short: I don't see the point, but it's up to be powers that be (namely the
nice and friendly ducarroz ;-) ).

Comment 1

[georgi - hopefully not receiving bugspam]

not sure if this bug is still valid.

can't include xml/xul in thunderbird/seamonkey.

fixed/invalid ?

Comment 2

[Ben Bucksch (:BenB)]

It's not about XML/XUL, but which code/parsers may be invoked by incoming messages. We can be extremely strict already (mailnews.display.disallow_mime_handlers=100, see <http://www.bucksch.org/1/projects/mozilla/108153/>, I added this specifically for you), but this bug was about being even more strict.

It was filed on your behalf, so if you don't need it: WONTFIX.

Comment 3

[georgi - hopefully not receiving bugspam]

so if you ask me i won't allow anything other than text/plain.
at best html would be converted to text/plain - no sanitizer.

won't get r/sr for this fo sure :)

Comment 4

[Ben Bucksch (:BenB)]

Actually, I got that already in :). There's a special feature for you to show the raw HTML source code, and to disallow almost all mime converters, but I assume you want to get attachments, so you need the mime multipart decoders at least. Please see the above URL for details. I think you want:
mailnews.display.prefer_plaintext = false (Ignore HTML parts in multipart/alternative)
mailnews.display.html_as = 2 (Show HTML source)
mailnews.display.disallow_mime_handlers = 100 (Use hardcoded whitelist to avoid even more bugs(buffer overflows). This mode will limit the features available (e.g. uncommon attachment types and inline images) and is for paranoid users.)

Comment 5

[Ben Bucksch (:BenB)]

s/false/true/

Comment 6

[georgi - hopefully not receiving bugspam]

(In reply to comment #4)
> Actually, I got that already in :). There's a special feature for you to show
> the raw HTML source code, and to disallow almost all mime converters, but I
> assume you want to get attachments, so you need the mime multipart decoders at
> least. Please see the above URL for details. I think you want:

ok, 10x. didn't read the full url - missed the ultra paranoid part :)