>>> 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. Most crashers don't crash pysandbox because they use features blocked by pysandbox, like the gc module. Others fail with a timeout. 3 tests are crashing pysandbox: - modify a dict during a dict lookup: I proposed two different fixes in issue #14205 - type MRO changed during a type lookup (modify __bases__ during the lookup): I proposed a fix in issue #14199 (keep a reference to the MRO during the lookup) - stack overflow because of a compiler recursion: we should limit the depth in the compiler (i didn't write a patch yet) pysandbox should probably hide __bases__ special attribute, or at least make it read-only. > 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 :-) It's possible to fix these crashers. In my experience, Python is very stable and has few crasher in the core language (e.g. compared to PHP). But I agree that it would be safer to run the untrusted code in a subprocess, by design. Running the code in a subprocess may be an option to provide higher level of security. Using a subprocess allows to reuse OS protections. Victor
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4