|Main Archive Page > Month Archives > oss-security archives|
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
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.
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