Front page | perl.pep |
Postings from September 2016
September 30, 2016 10:48
Message ID: 201609301238.18664@pali
On Wednesday 28 September 2016 15:29:28 Ricardo Signes wrote:
> * email@example.com [2016-09-18T11:40:53]
> > Currently passing string values of From/To/Cc/Bcc/... headers into
> > header_str() method is broken in Email::MIME. That is because
> > Email::MIME currently uses Email::Address for generating those
> > header values (which is broken) and then MIME encode those broken
> > outputs.
> > Email::Address::XS has (looks like) correctly implemented formatter
> > and so it is needed to correctly MIME encode From/To/Cc/Bcc
> > headers.
> I suggest making Email::MIME use Email::Address::XS if it is
> available, and adding Email::Address::XS to the recommended prereqs
> of Email::MIME. The right behavior will be easy to get, and usually
> be installed, but it will be possible to proceed with less correct
> behavior if you haven't got a compiler (for some sad reason).
> Part of the question is: how wrong do things go, in what
> circumstances, if Email::Address is substituted for
First problem is CVE-2015-7686. If you pass "unsafe" string into
Email::Address then perl starts eating CPU for a very long period.
Next problem with Email::Address is that it eats names of email groups.
Which means that if you ask or pass MIME-decoded string version of raw
You will just get:
Another problem is parsing name/phrase which have MIME encoded string
which "looks like" an email address. E.g. for MIME header:
To: =?UTF-8?B?PG15Pg==?= <firstname.lastname@example.org>
You will get MIME-decoded string:
To: <my@name>, <email@example.com>
Because just of first problem CVE-2015-7686, I would really suggest to
totally avoid using Email::Address. If you process "unsafe" email from
attacker on some server, you get perfect DOS attack.
I think that returning original header (not MIME decoded) or croaking is
better then using Email::Address.
> > As compromise could be: Whole Email::MIME will not depends on
> > module Email::Address::XS. But if somebody want to pass Unicode
> > string (via header_str) to Email::MIME then MIME encoding will be
> > done via Email::MIME::Header::AddressList (which will use
> > Email::Address::XS). So if caller encodes manually From/To/Cc/...
> > headers and pass them via header_raw() then Email::Address::XS
> > will not be needed.
> Specifically, I think, a non-ASCII string. I'm guessing that
> most/many users are really just passing in fixed ASCII strings, so
> this rule wouldn't affect them at all. Users passing in non-ASCII
> would start getting a "automatic encoding of non-ASCII $field header
> requires ...." error. Seems okay.
> > And can be Email::MIME::Header::AddressList part of Email-MIME
> > distribution (even if only this module will depends on XS)?
> I guess so. We need to mark this stuff experimental for a while, I
> think, too.
I think now we discussed everything needed... I will implement patches
for Email::MIME and will see how it is usable and how it is working...