classification
Title: Potential DoS Attack when Parsing Email with Huge Number of MIME Parts
Type: security Stage:
Components: email Versions: Python 3.6, Python 3.5
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: barry, christian.heimes, ckossmann, r.david.murray
Priority: normal Keywords:

Created on 2017-09-13 12:19 by ckossmann, last changed 2017-09-13 13:34 by r.david.murray.

Files
File name Uploaded Description Edit
multipart-dos-attack.py ckossmann, 2017-09-13 12:19 proof-of-concept
Messages (2)
msg302060 - (view) Author: Christian KoƟmann (ckossmann) Date: 2017-09-13 12:19
Python's email parser consumes a lot of resources (CPU and memory) when parsing emails with a large amount of MIME parts. Attackers can probably exploit this behavior to perform denial-of-service (DoS) attacks.

A potentially malicious email has the following structure:

=============================================
From: sender@example.com
To: recipient@example.com
Subject: Mutlipart DoS Attack
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="n"

This is a multi-part message in MIME format.
--n

b

--n

... a lot of parts here...

--n

b

--n--
=============================================

On my machine parsing an email with 1 million MIME parts takes around 20 seconds and with 10 million MIME parts over 3 minutes.

In my opinion, the number of MIME parts should be limited to some reasonable value to mitigate this kind of attack. The bug report contains a Python script with a proof-of-concept.
msg302075 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-13 13:34
10 million mime parts?  That sounds like the kind of thing rfc 1870 was designed to address in a more general fashion (ie: the SMTP server should be enforcing maximum message size if you are worried about DOS attacks).

1 million = 3 seconds, 10 million = "over three minutes" sounds like a linear increase, so I don't see that there is anything special about "mime parts" in this scenario.

I have no objection to PRs making the parsing more efficient, though :)
History
Date User Action Args
2017-09-13 13:34:50r.david.murraysetnosy: + christian.heimes
messages: + msg302075
2017-09-13 12:19:54ckossmanncreate