[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150930071507.90DE21BE293@smtpvbsrv1.mitre.org>
Date: Wed, 30 Sep 2015 03:15:07 -0400 (EDT)
From: cve-assign@...re.org
To: pali.rohar@...il.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: DoS attack through Email-Address perl module v1.907 (CVE id request)
-----BEGIN PGP SIGNED MESSAGE-----
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 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."
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCAAGBQJWC4tDAAoJEL54rhJi8gl5xo8P/ityH+Lo6SY0SoCwruealNVP
6/7OHZftSAtpsSp5YBok280FIwK+J2cm11Sj2O7Xzwm9LOwNFOAjNz8nQN2HyueK
y4adxpY8NyIiEP7PKichUOtE5+ykJTeV8UBDDP1ZHGHD6sbRy7Z9EEx9RtXX3MxT
IaqvcYUfvi/YmBB1j/lvhNtT8PkI8arEs7dPOfIcVDwnIfr+yW1vp95xKWIpNXvN
YCeO4ku5SRt5w6c2qultSk0RrgjPHaRBikLNvFScBBqrYnS0v4qquteCgf/l2/SD
i3wFaXVudKdQF8TXhhwia1ydfcnATet1oxKJNxp2RUyBhufFHAI59EwxC2VHcaSL
I5v/F0mfNZSup+RHs9NkRWMRPpG4uZMfI13oO1pb52zdekg7Maetz3omm3kPRldn
3o0Hx0lVHb1LFE8CtuowZgEFde/6yL6Pfp2vgAY1ago5j0DRp4XiSIsqHQBzRm3h
azE/AeuFYm/SCDvXP3HEEgQ2rHajJT5UvlsKVY8KlzHq0qqWAShDVBrffa+cJF2j
ibEASbLr3SrleeDAU0r+DCyRC7j35Nby0WCl5PwQGo88YAL52HifDukjcrfJ6b2U
BU3Y15zBprq5Bu92tzsxL94KTyEpiztXJuntNMsJxgXI5gSPFr3zWcffEsqbFO7K
GJ9shcLdixnAgS9SEH6E
=Iv35
-----END PGP SIGNATURE-----
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.
