headers
Sturla Molden | 2 Jul 2010 06:03
Picon
Gravatar

Re: [Cython] Py 2.7 deprecates PyCObject

Lisandro Dalcin skrev:
> In Python 2.7, creating a PyCObject is marked with
> PendingDeprecationWarning... Should we special case 2.7 and use
> PyCapsule ?
>
>   
All programs that use PyCObject become a security problem. PyCObject 
makes no "type checks" on the void pointer, and can therefore be used to 
crash the interpreter or execute exploit code as destructor. "Type 
checking" void pointers might seem like a misnomer. But what PyCapsule 
does is to associalte the pointer with a name (a character string), that 
sort of acts like an access password or run-time type information.

Sturla
Permalink | Reply |
headers
Lisandro Dalcin | 2 Jul 2010 06:46
Picon
Gravatar

Re: [Cython] Py 2.7 deprecates PyCObject

On 2 July 2010 01:03, Sturla Molden <sturla@...> wrote:
> Lisandro Dalcin skrev:
>> In Python 2.7, creating a PyCObject is marked with
>> PendingDeprecationWarning... Should we special case 2.7 and use
>> PyCapsule ?
>>
>>
> All programs that use PyCObject become a security problem. PyCObject
> makes no "type checks" on the void pointer, and can therefore be used to
> crash the interpreter or execute exploit code as destructor. "Type
> checking" void pointers might seem like a misnomer. But what PyCapsule
> does is to associalte the pointer with a name (a character string), that
> sort of acts like an access password or run-time type information.
>

1) PyCObject_FromVoidPtrAndDesc() and PyCObject_GetDesc() serve to
associate extra info on the pointer.

2) IMHO, the way to better handle the security issue is by providing
slots and API's in module and type objects.

But at this point, discussing on this is pointless. I'm just asking if
Cython should avoid the warning/error when running under "python -W
default/error ..." . I think we should fix it, I volunteer to do it.

Sturla, I should count your comment as a +1, right?. What other people think?

--

-- 
Lisandro Dalcin
---------------
(Continue reading)

Permalink | Reply |
headers
Stefan Behnel | 2 Jul 2010 08:21
Picon
Favicon

Re: [Cython] Py 2.7 deprecates PyCObject

Sturla Molden, 02.07.2010 06:03:
> All programs that use PyCObject become a security problem. PyCObject
> makes no "type checks" on the void pointer, and can therefore be used to
> crash the interpreter or execute exploit code as destructor.

Like that was hard to do from C code.

Stefan
Permalink | Reply |
headers
Sturla Molden | 2 Jul 2010 14:06
Picon
Gravatar

Re: [Cython] Py 2.7 deprecates PyCObject


Den 2. juli 2010 kl. 08.21 skrev Stefan Behnel <stefan_ml@...>:

> Sturla Molden, 02.07.2010 06:03:
>> All programs that use PyCObject become a security problem. PyCObject
>> makes no "type checks" on the void pointer, and can therefore be  
>> used to
>> crash the interpreter or execute exploit code as destructor.
>
> Like that was hard to do from C

PyCObject opens for exploits from Python code.

Sturla
Permalink | Reply |
headers
Stefan Behnel | 2 Jul 2010 14:16
Picon
Favicon

Re: [Cython] Py 2.7 deprecates PyCObject

Sturla Molden, 02.07.2010 14:06:
> Den 2. juli 2010 kl. 08.21 skrev Stefan Behnel:
>
>> Sturla Molden, 02.07.2010 06:03:
>>> All programs that use PyCObject become a security problem. PyCObject
>>> makes no "type checks" on the void pointer, and can therefore be
>>> used to
>>> crash the interpreter or execute exploit code as destructor.
>>
>> Like that was hard to do from C
>
> PyCObject opens for exploits from Python code.

Seriously, if I can make you run my Python code on your server, I doubt 
that PyCObject is your main problem.

Stefan
Permalink | Reply |
headers
Dag Sverre Seljebotn | 2 Jul 2010 14:31
Picon
Picon

Re: [Cython] Py 2.7 deprecates PyCObject

Stefan Behnel wrote:
> Sturla Molden, 02.07.2010 14:06:
>   
>> Den 2. juli 2010 kl. 08.21 skrev Stefan Behnel:
>>
>>     
>>> Sturla Molden, 02.07.2010 06:03:
>>>       
>>>> All programs that use PyCObject become a security problem. PyCObject
>>>> makes no "type checks" on the void pointer, and can therefore be
>>>> used to
>>>> crash the interpreter or execute exploit code as destructor.
>>>>         
>>> Like that was hard to do from C
>>>       
>> PyCObject opens for exploits from Python code.
>>     
>
> Seriously, if I can make you run my Python code on your server, I doubt 
> that PyCObject is your main problem.
>   
Google AppEngine, that kind of stuff. The point would be to make it 
faster to audit the code for such purposes, I think.

Dag Sverre
Permalink | Reply |
headers
Stefan Behnel | 2 Jul 2010 14:46
Picon
Favicon

Re: [Cython] Py 2.7 deprecates PyCObject

Sturla Molden, 02.07.2010 06:03:
> But what PyCapsule
> does is to associalte the pointer with a name (a character string), that
> sort of acts like an access password or run-time type information.

Note that Pyrex and Cython have been using this mechanism right from the 
beginning, when PyCapsule wasn't even in the makings. This has nothing to 
do with "security", just "safety" at most.

Stefan
Permalink | Reply |
headers
Lisandro Dalcin | 2 Jul 2010 16:00
Picon
Gravatar

Re: [Cython] Py 2.7 deprecates PyCObject

On 2 July 2010 09:46, Stefan Behnel <stefan_ml@...> wrote:
> Sturla Molden, 02.07.2010 06:03:
>> But what PyCapsule
>> does is to associalte the pointer with a name (a character string), that
>> sort of acts like an access password or run-time type information.
>
> Note that Pyrex and Cython have been using this mechanism right from the
> beginning, when PyCapsule wasn't even in the makings. This has nothing to
> do with "security", just "safety" at most.
>

Please focus :-) and comment on my original questions... Should Cython
switch to PyCapsule for Py>=2.7 && Py<3.0 ??

--

-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169
Permalink | Reply |
headers
Greg Ewing | 3 Jul 2010 04:02
Picon
Picon
Favicon

Re: [Cython] Py 2.7 deprecates PyCObject

Sturla Molden wrote:

> All programs that use PyCObject become a security problem.

It's not quite true to say "all" here, because it's possible
to use the descr slot of a PyCObject to hold type information.

However, that's not the purpose that the docs advertise it as
being for, and there's probably a lot of PyCObject-using code
around that doesn't use it that way. So replacing PyCObject with
something more explicitly safe seems like a good idea.

--

-- 
Greg
Permalink | Reply |

Gmane