Email Header Injection Protection Bypass

[thedoctorsoup]

BPO	32606
Nosy	@warsaw, @bitdancer, @csabella, @nitishch, @thedoctorsoup
Files	PythonEmailHeaderInjectionPOC.py: Bypass Proof of Concept

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-01-21.05:40:52.579>
labels = ['type-security', 'library']
title = 'Email Header Injection Protection Bypass'
updated_at = <Date 2018-09-29.16:09:33.569>
user = 'https://github.com/thedoctorsoup'

bugs.python.org fields:

activity = <Date 2018-09-29.16:09:33.569>
actor = 'cheryl.sabella'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2018-01-21.05:40:52.579>
creator = 'thedoctorsoup'
dependencies = []
files = ['47396']
hgrepos = []
issue_num = 32606
keywords = []
message_count = 4.0
messages = ['310367', '310904', '310911', '326682']
nosy_count = 5.0
nosy_names = ['barry', 'r.david.murray', 'cheryl.sabella', 'nitishch', 'thedoctorsoup']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue32606'
versions = []

[thedoctorsoup]

The protection's implemented in https://github.com/python/cpython/blob/master/Lib/email/header.py to prevent Email Header injection can be bypassed by specifying an injected additional header in the following format:
example@python.org\ncc :injected@python.org

The white space bypasses the current regex protection (_embedded_header = re.compile(r'\n[^ \\t]+:')) and is still accepted by the smtp server.

Attached is a proof of concept script

[nitishch]

RFC 5322[1] says that header field's name can't have space in it and the must be immediately followed by the ':' character.

Is it common for SMTP servers to accept messages with ' ' before ':'?

[1] https://tools.ietf.org/html/rfc5322#section-2.2

[bitdancer]

Yes.

There's this thing called Postel's Law that says you should be generous in what you accept and careful in what you emit. So most MTAs and MUAs try very hard to guess what a non-RFC-compliant email is trying to say, which includes allowing spaces between the label and the colon (which I believe was legal at least in RFC 822, though I haven't checked). If there's a space in the label, the handling for that is less predictable. The email library's default is to treat that as a non-header line and therefor the start of the body (even if not followed by a blank line).

[csabella]

Should this be closed as 'not a bug'?

[vstinner]

It seems like the email header injection vulnerability is supposed to be fixed since Python 3.5: https://python-security.readthedocs.io/vuln/http-header-injection.html

The problem here is the usage of the generic email.mime.multipart.MIMEMultipart which uses the default policy. To format an email, you should use the stricter EmailPolicy which disallows newline characters.

@warsaw @bitdancer @maxking @giampaolo: Would it be possible to change the default email policy to a stricter policy which reject newline characters? What are the contraints for backward compatibility here?

Or is it a documentation issue?

[bitdancer]

The regex in email/header.py should be fixed. The fix is pretty simple, just allowing for whitespace to appear before the colon.