Re: CVE Request -- Python -- accept() implementation in async core is broken => more subcases

["Steven M. Christey" <coley () linus mitre org>]

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