Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 24 Sep 2010 14:08:01 -0400 (EDT)
From: "Steven M. Christey" <>
cc: David Malcolm <>,
        "Steven M. Christey" <>
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 

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 - 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.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.