On Sat, Mar 3, 2012 at 6:51 PM, Guido van Rossum <gu...@python.org> wrote: > On Sat, Mar 3, 2012 at 6:02 PM, Maciej Fijalkowski <fij...@gmail.com> wrote: >> On Sat, Mar 3, 2012 at 1:37 PM, Victor Stinner <victor.stin...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com