Is python buffer overflow proof?
gagsl-py2 at yahoo.com.ar
Tue Aug 4 03:39:50 CEST 2009
En Mon, 03 Aug 2009 18:04:53 -0300, sturlamolden <sturlamolden at yahoo.no>
> 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 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
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
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.
More information about the Python-list