Issue 19470: email.header.Header - should not allow two newlines in a row (original) (raw)

Issue19470

Created on 2013-11-01 09:13 by hhm, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (4)
msg201884 - (view)	Author: hhm (hhm)	Date: 2013-11-01 09:13
An email.header.Header object should not allow two consecutive newlines, since this terminates interpretation of headers and starts the body section. This can be exploited by an attacker in a case of user input being used in headers, and validated with the Header object, by stopping interpretation of any further headers, which become interpreted by an user (or other) agent. This in turn can be used to modify the behavior of emails, web pages, and the like, where such code is present.
msg201885 - (view)	Author: hhm (hhm)	Date: 2013-11-01 09:14
(see also http://bugs.python.org/issue5871)
msg201898 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2013-11-01 13:36
I'm not sure how appropriate it is to "validate" a header using the Header object. Header is for *composing* internationalized headers, and does no validation to speak of. However, if you'd like to write a patch to add this check, I would probably commit it, since it is analogous to issue 5871. However, since the security issue was already dealt with in issue 5871, this fix would be a convenience (detecting the issue earlier). On the flip side, it would also be a behavior change, so there might be objections to backporting it. (Do any programs use Header for things other than composing email messages and actually rely on embedded newlines? I hope not, but you never know :) Further, if you use the new policies available in 3.3 and 3.4 (currently provisional, but they are the Way of the Future ;), you don't ever need to use Header objects, and embedded newlines are rejected as soon as you try to assign a string containing them as a header value in a message object.
msg212324 - (view)	Author: R. David Murray (r.david.murray) *	Date: 2014-02-26 23:24
Having thought further about this (prompted by a suggested fix by Varun Sharma), I'm going to reject it. The reason is that the email package in 3.2 compatibility mode still uses the Header object to encapsulate headers that have invalid binary data in them. This means that if we added the check to Header, the email package could throw errors at unexpected times (that is, when retrieving a header from a parsed message). In retrospect I think returning a Header object for invalid data was probably a bad idea, but what's done is done.