Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Sep 2015 03:15:07 -0400 (EDT)
Subject: Re: DoS attack through Email-Address perl module v1.907 (CVE id request)

Hash: SHA256

> 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.

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 address strings, e.g., do a web
search for either of these: (Jan Smith (MSFT)) (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

  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."

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


Powered by blists - more mailing lists

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

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.