[Python-Dev] Sandboxing Python (original) (raw)

Maciej Fijalkowski fijall at gmail.com
Sun Mar 4 04:41:58 CET 2012

On Sat, Mar 3, 2012 at 6:51 PM, Guido van Rossum <guido at python.org> wrote:

On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski <fijall at gmail.com> wrote:

On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner <victor.stinner at gmail.com> wrote:

Hi,

Le 03/03/2012 20:13, Armin Rigo a écrit :

I challenge anymore to break pysandbox! I would be happy if anyone breaks it because it would make it more stronger.

I tried to run the files from Lib/test/crashers and --- kind of obviously --- I found at least two of them that still segfaults execfile.py, sometimes with minor edits and sometimes directly, on CPython 2.7. As described in the README file of pysandbox, pysandbox doesn't protect against vulnerabilities or bugs in Python. As usual, I don't see the point of "challenging" us when we have crashers already documented.  Also, it's not like Lib/test/crashers contains in detail all crashers that exist; some of them are of the kind "there is a general issue with xxx, here is an example". If you are not concerned about segfaults but only real attacks, then fine, I will not spend the hours necessary to turn the segfault into a real attack :-) You may be able to exploit crashers, but I don't plan to workaround such CPython bug in pysandbox. I'm looking for vulnerabilities in pysandbox, not in CPython. Victor Well ok. But then what's the point of "challenging" people? You say "this is secure according to my knowledge" and when armin says "no it's not", you claim this is the wrong kind of security exploit. Segfaults (most of them) can generally be made into arbitrary code execution, hence the pysandbox is not quite secure. Even further, "any" sort of this "security restrictions" where you modify locals globals etc. would be seriously prone to attacks like those segfaults, unless you do something with the VM you're running. This makes it slightly less convincing to argue that the VM requires new features (in this case frozendict) in order to support the kind of program that's broken in the first place. Well, I think I'm seriously missing something. Could we put asserts in the places where segfaults may happen? Then Victor could say "if you want this to be secure then you must build your Python executable with asserts on." IIRC some of the segfaults already trigger asserts when those are enabled.

It's easy for some cases. Stack exhaustion cases might be significantly harder although you might pass some compiler-specific options to defend against that. The problem is a bit that those are "examples", which mean that they might either touch specific parts of code or "code that looks like that". A good example of a latter is chaining of iterators. Any iterators that can be chained can be made into a stack exhaustion segfault.

I suppose with a bit of effort it might be made significantly harder though.

Cheers, fijal

More information about the Python-Dev mailing list