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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ