1423430 - Mailsploit (tracking)

Status: RESOLVED WORKSFORME

(MailNews Core :: MIME, enhancement)

Description

https://www.mailsploit.com / https://web.archive.org/web/20180311092138/https://www.mailsploit.com/index

Reproduction:
1. Send yourself an email with SMTP:
$ netcat ###YOUR.SMTP.SERVER### 25
MAIL FROM:<=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com>
RCPT TO: <###[e-mail]###>
DATA
From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
To: [e-mail]
Date: Wed, 6 December 2017 22:00:00 +0200
Subject: mailsploit

Yeah, right.

.
QUIT

2. Open the email in Thunderbird

Actual result:
* The From field displays:
"[e-mail]
* If you click on the email address, you still see the same email address in the context menu.

Expected result:
* The From field displays:
[e-mail]
or even better:
[e-mail]

Comment 2

[Ben Bucksch (:BenB)]

Attachment: Screenshot of bug

Comment 3

[Ben Bucksch (:BenB)]

Analysis:
I think the bug here is that we cut display off an embedded null \0 character. Instead, we should strip the null.

More generally, we should not try to decipher everything that the email standard allows in freaky email addresses. We tried really hard to properly decode things according to the internet standards, but I think that's a bad idea from a security perspective. The standards are decades old and tried to support systems that no longer exist. We should deliberately *not* support escape sequences in email addresses, and strip anything that's unusual.

We should only allow today's normal email addresses, that is alphanumeric characters, and a few common special characters like ".", "-", "_", "+".

In the real name field (not email address), we should support international characters, but even there we should deliberately forbid the "@" character and strings that look like domains in display names, to prevent spoofing.

Comment 4

[Ben Bucksch (:BenB)]

Filed more specific bugs to avoid spoofing in the From header:
Bug 1423432 - From addresses with null character are cut off
Bug 1423437 - Do not unescape email addresses
Bug 1423439 - Strip highly unusual characters from the email address
Bug 1423440 - Remove @ from real name
Bug 1423444 - Remove domains from real name part

Comment 5

[Jorg K (CEST = GMT+2)]

IMHO, I'd only fix bug 1423432. I will comment there further.

Comment 6

[Ben Bucksch (:BenB)]

This is a tracking bug, it's not for discussion and opinion.

Comment 7

[Adrian Zaugg]

I know this is a tracking bug, but in my opinion the problem must be discussed as a whole. The splitting into sub problems already includes some assumptions made. And: The representation or handling of an invalid address concerns probably all sub problems.

The RFC about mail header extensions RFC 2047, section 5 [1] has some recommendations about encoding, which applies to all sub bugs of this one:

on page 7:
- "An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'."
- "An 'encoded-word' MUST NOT appear within a 'quoted-string'."
- [...] "'encoded-text' MUST NOT be continued from one 'encoded-word' to
   another"
- "Only printable and white space character data should be encoded using
   this scheme."

on page 6, under (1):
- "However, an 'encoded-word' that appears in a header field defined as
   '*text' MUST be separated from any adjacent 'encoded-word' or 'text'
   by 'linear-white-space'"

So, such from-addresses as the mailsploit attack should not occur.
Therefore, probably the most relevant part of the RFC is:

   "Only printable and white space character data should be encoded using
   this scheme.  However, since these encoding schemes allow the
   encoding of arbitrary octet values, mail readers that implement this
   decoding should also ensure that display of the decoded data on the
   recipient's terminal will not cause unwanted side-effects."
   (page 7, second last paragraph)


[1] https://tools.ietf.org/html/rfc2047#section-5

Comment 8

[Ben Bucksch (:BenB)]

Adrian, that's more or less what I've been suggesting in the sub-bugs. Thanks for the RFC quote to support it.

Comment 10

[Wayne Mery (:wsmwk)]

With only one open blocking bug, the value of tracking a "collection" no longer exists.