Open Bug 1423430 Opened 2 years ago Updated 2 years ago

Mailsploit (tracking)

Categories

(MailNews Core :: MIME, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: BenB, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: meta)

Attachments

(1 file)

https://www.mailsploit.com

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: <###your.email.address@your.own.provider.not.gmail.and.co###>
DATA
From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@mailsploit.com
To: moron@example.com
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:
"potus@whitehouse.gov
* If you click on the email address, you still see the same email address in the context menu.

Expected result:
* The From field displays:
-potus-whitehouse.gov@mailsploit.com
or even better:
invalid@mailsploit.com
Duplicate of this bug: 1423319
Attached image Screenshot of bug
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.
Depends on: CVE-2017-7829
Depends on: 1423437
Depends on: 1423439
Depends on: 1423440
Depends on: 1423444
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
Keywords: meta
Summary: Mailsploit: From addresses with null character are cut off → Mailsploit: From address spoofing despite DKIM/SPF (tracking)
Summary: Mailsploit: From address spoofing despite DKIM/SPF (tracking) → Mailsploit (tracking)
IMHO, I'd only fix bug 1423432. I will comment there further.
This is a tracking bug, it's not for discussion and opinion.
Group: mail-core-security
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
Adrian, that's more or less what I've been suggesting in the sub-bugs. Thanks for the RFC quote to support it.
Duplicate of this bug: 1424804
You need to log in before you can comment on or make changes to this bug.