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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ