[Python-Dev] Let's update CObject API so it is safe and regular!

Guido van Rossum guido at python.org
Thu Apr 2 04:08:56 CEST 2009


On Wed, Apr 1, 2009 at 5:39 PM, Larry Hastings <larry at hastings.org> wrote:
>
> Guido van Rossum wrote:
>
> This is a bug in cPickle. It calls the PycString_IMPORT macro at the
> very end of its init_stuff() function without checking for success.
>
>
> The bug you cite is a genuine bug, but that's not what I'm exploiting.
>
> % python
>>>> import _socket
>>>> _socket.CAPI
> <PyCObject object at 0xb7d5b500>
>
> The PyCObject_Import() call in PycString_IMPORT doesn't return failure--it
> returns a valid CObject.  I stuck the *wrong* CObject in cStringIO on
> purpose.  With the current API there's no way for cPickle to tell that it's
> using the wrong one.

Ouch. So true.

> For what it's worth, the previous example was for Python 2.x.  (Python 3
> doesn't have "cStringIO" or "cPickle".)  Here's an example that crashes
> python in my py3k/trunk (sync'd Monday morning).  And this one's only three
> lines:
>
> import unicodedata
> import _multibytecodec
> _multibytecodec.__create_codec(unicodedata.ucnhash_CAPI)

Yeah, any two CAPI objects can be used to play this trick, as long as
you have some place that calls them. :-(

So what's your solution? If it was me I'd change the API to put the
full module name and variable name of the object inside the object and
have the IMPORT call check that. Then you can only have crashes if
some extension module cheats, and surely there are many other ways
that C extensions can cheat, so that doesn't bother me. :)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list