Is python buffer overflow proof?

[Gabriel Genellina]

En Mon, 03 Aug 2009 18:04:53 -0300, sturlamolden <sturlamolden at yahoo.no>  
escribió:

> On 2 Aug, 15:50, Jizzai <jiz... at gmail.com> wrote:
>
>> Is a _pure_ python program buffer overflow proof?
>>
>> For example in C++ you can declare a char[9] to hold user input.
>> If the user inputs 10+ chars a buffer overflow occurs.
>
> Short answer: NO
>
> Bounds checking on sequence types is a protection against buffer
> overflow, but is certainly not sufficient.
>
> The Python interpreter is written in C. Python extension modules are
> written in C (or something similar). If you find an unprotected buffer
> in this C code, you can possibly overflow this buffer. This can be
> used for nasty things like corrupting the stack and injecting
> malicious code. There is a reason why the Python sandbox (rexec and
> Bastion modules) was disabled in Python 2.3.

(I think the reason rexec and bastion were disabled has nothing to do with  
the possibility of buffer overflows in extension modules)

> IronPython and Jython provides better protection against buffer
> overflow than CPython, as these interpreters are written in safer
> languages (C# and Java). You thus get an extra layer of protection
> between the Python code and the unsafe C (used in JVM and .NET
> runtimes).

I disagree. You've just translated the responsability to check for buffer  
overflows, from the Python VM, to the Java VM or the .Net runtime (and all  
three suffered from buffer overruns and other problems in some way or  
another). Also, Python extensions written in C are equivalent to using JNI  
in Java or unmanaged code in C#: all three are likely to have hidden  
problems.
It's always the same story: a *language* may declare that such things are  
impossible, but a particular *implementation* may have bugs and fail to  
comply with the specification.

-- 
Gabriel Genellina