Date: Fri, 24 Sep 2010 14:08:01 -0400 (EDT) From: "Steven M. Christey" <coley@...us.mitre.org> To: oss-security@...ts.openwall.com cc: David Malcolm <dmalcolm@...hat.com>, "Steven M. Christey" <coley@...us.mitre.org> Subject: Re: CVE Request -- Python -- accept() implementation in async core is broken => more subcases On Wed, 22 Sep 2010, Josh Bressers wrote: > Any update on this Steve? This was a weird one to deal with. There are a couple different approaches. We don't capture API "design limitations" in CVE (it would basically be like assigning a CVE to "strcpy can be called with parameters that are longer than the output buffer" or "setuid requires that the programmer must check the return code to ensure that privileges were dropped.") In this case, there is a "proper" way to handle the accept() behavior; i.e. by catching the appropriate exceptions and accounting for an unusual return value, the programmer can use the API safely. That would argue for treating it like strcpy/setuid/etc. design limitations, and holding application programmers "responsible" for using it incorrectly. However, there isn't some security-relevant documentation about these specific API limitations. So, a CVE could be assigned for the missing documentation; alternately, we could treat it as "undocumented behavior" in the API. (This wouldn't be the first CVE related to documentation.) Then, individual programs that happen to use the unpatched/older Pythons can be held responsible for not accounting for this; similar to how we "blame" applications for allowing XSS due to some non-standard implementations within Internet Explorer, or Firefox, etc. So: CVE-2010-3492 - Python poor documentation of accept() behavior CVE-2010-3493 - smtpd.py not catching errors generated by handle_accept CVE-2010-3494 - pyftpdlib not catching errors generated by handle_accept CVE-2010-3495 - ZODB not catching errors generated by handle_accept - Steve
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