Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Oct 2015 18:58:31 +0200
From: Pali Rohár <pali.rohar@...il.com>
To: cve-assign@...re.org
Cc: oss-security@...ts.openwall.com
Subject: Re: DoS attack through Email-Address perl module v1.907 (CVE id request)

On Wednesday 30 September 2015 09:15:07 cve-assign@...re.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@....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@...ine.microsoft.com (Jan Smith (MSFT))
>   evanba@...ine.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@....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@...ine.microsoft.com (Jan Smith (MSFT)), evanba@...ine.microsoft.com (Evan T. Basalik (MSFT))"

with nest level 2 is parsed as:

$VAR1 = [
          [
            'Jan Smith ',
            'jsmit@...ine.microsoft.com'
          ],
          [
            'Evan T. Basalik ',
            'evanba@...ine.microsoft.com'
          ]
        ];

and with nest level 1 as:

$VAR1 = [
          [
            'jsmit',
            'jsmit@...ine.microsoft.com'
          ],
          [
            'evanba',
            'evanba@...ine.microsoft.com'
          ]
        ];

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

Next, string 

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

with nest level 2 as:

$VAR1 = [
          [
            'hide address from spambot ',
            'Chamberlain@....US'
          ]
        ];

and with nest level 1 as:

$VAR1 = [
          [
            'Chamberlain',
            'Chamberlain@....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@...il.com

Download attachment "signature.asc " of type "application/pgp-signature" (199 bytes)

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ