Open Bug 1423430 Opened 2 years ago Updated 2 years ago
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?cG90dXNAd2hpdGVob3VzZS5nb3Yemail@example.com> RCPT TO: <###firstname.lastname@example.org###> DATA From: =?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Yemail@example.com To: firstname.lastname@example.org 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: "email@example.com * If you click on the email address, you still see the same email address in the context menu. Expected result: * The From field displays: -firstname.lastname@example.org or even better: email@example.com
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.
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
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.
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  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)  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.
Depends on: 1427382
You need to log in before you can comment on or make changes to this bug.