Re: DoS attack through Email-Address perl module v1.907 (CVE id request)

[Pali Rohár <pali.rohar () gmail com>]

On Wednesday 30 September 2015 09:15:07 cve-assign () mitre org wrote:
> > Probably nobody has normal usage for inserting nested comments
> > into email address in To:/Cc: headers...
>
> It may be reasonable to assign one CVE ID for the Email::Address
> issue; however, the decision may depend somewhat on this information
> about normal usage. See below for a question about the behavior of
> the patched version.
>
> > Because input string for Email::Address module comes from external
> > source (e.g. from email sent by attacker) it is security problem
> > all software application which parse email messages by
> > Email::Address perl module. For example: RT: Request Tracker,
> > CiderWebmail, ...
>
> The documentation says it "locates email addresses in strings" and
> this might not always mean "from external source." Thus, one might
> argue that it is not a vulnerability in a general-purpose utility
> such as Email::Address, and instead is a vulnerability in each
> individual application that uses Email::Address without changing the
> $Email::Address::COMMENT_NEST_LEVEL package variable to satisfy that
> application's threat model.

Standard usage of Email::Address module is to parse From/To/Cc headers from emails. And standard is also to use that 
module without setting $COMMENT_NEST_LEVEL variable... So because I was thinking about this standard usage in other 
applications I think that one CVE ID could be enough.

> However, we think one CVE ID may be enough if, realistically, no
> application ever needed $COMMENT_NEST_LEVEL to have a value of 2,
> i.e., changing from 2 to 1 does not break anything.
>
> We think there may be two distinct cases of nested comments:
>
>   A. each nested comment is either entirely before or entirely after
>      the address
>
>   B. the nested comment is inside the address, similar to the
>      "Wilt . (the  Stilt) Chamberlain () NBA US" example from
>      RFC 822 section A.1.4
>
>
> In case A, if $COMMENT_NEST_LEVEL is reduced, is correctness
> affected? Or does the module always still find the correct address
> string (and typically faster)?
>
> We would guess that correctness is affected in case B.
>
> As far as we know, case A sometimes occurs in real life. The example
> we found is online.microsoft.com address strings, e.g., do a web
> search for either of these:
>
>   jsmit () online microsoft com (Jan Smith (MSFT))
>   evanba () online microsoft com (Evan T. Basalik (MSFT))
>
> As far as we know, case B essentially never occurs in the standard
> format of an address string, although it might occur in something
> like:
>
>   Wilt . (hide address from spambot(s)) Chamberlain () NBA US
>
> All of the above discussion implies that the CVE ID would be assigned
> for the concept of "the default configuration is unsafe." This is,
> for most purposes, largely equivalent to the concept of "the
> computational complexity of the comment-parsing algorithm is too
> high."

One important note is that Email::Address is not fully RFC compliance.
And some strings are not parsed correctly according to RFCs...

For example string

  "jsmit () online microsoft com (Jan Smith (MSFT)), evanba () online microsoft com (Evan T. Basalik (MSFT))"

with nest level 2 is parsed as:

$VAR1 = [
          [
            'Jan Smith ',
            'jsmit () online microsoft com'
          ],
          [
            'Evan T. Basalik ',
            'evanba () online microsoft com'
          ]
        ];

and with nest level 1 as:

$VAR1 = [
          [
            'jsmit',
            'jsmit () online microsoft com'
          ],
          [
            'evanba',
            'evanba () online microsoft com'
          ]
        ];

(in both cases first value is name(), second address())

Next, string 

  "Wilt . (hide address from spambot(s)) Chamberlain () NBA US"

with nest level 2 as:

$VAR1 = [
          [
            'hide address from spambot ',
            'Chamberlain () NBA US'
          ]
        ];

and with nest level 1 as:

$VAR1 = [
          [
            'Chamberlain',
            'Chamberlain () NBA US'
          ]
        ];

Probably there could be examples when email address (not name) is parsed
differently with nest level 1 and 2, but those provides examples just
provide same output for email addresses. Here I'm not talking about
correctness of that module, but about differences (nest level 1 and 2).

Btw, Email::Address module is not written by me. For it is black box as
it generates some perl regexp at runtime which I did not try to fully
understand. So I do not know how exactly parser works and it is hard for
me to answer how parser is changed if nest level 2 is changed to 1. I
just discovered that performance problem with nest level 2 on some
special strings (which I sent in previous email).

Personally I would classify changing nest level 2 to 1 as security fix
for default settings. Email::Address is not fully RFC compliance so even
before it returned in some cases incorrect result (according to RFC).

-- 
Pali Rohár
pali.rohar () gmail com

Attachment: signature.asc
Description: This is a digitally signed message part.