oss-security September 2010 archive
Main Archive Page > Month Archives  > oss-security archives
oss-security: Re: [oss-security] CVE Request -- Python -- accept

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

From: Steven M. Christey <coley_at_nospam>
Date: Fri Sep 24 2010 - 18:08:01 GMT
To: oss-security@lists.openwall.com

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