[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

[Oscar Benjamin]

On 10 Apr 2016 22:55, "Jon Ribbens" <jon+python-dev at unequivocal.co.uk>
wrote:
>
> On Mon, Apr 11, 2016 at 12:07:48AM +0300, Serhiy Storchaka wrote:
> > On 10.04.16 19:51, Jon Ribbens wrote:
> > >On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote:
> > >>On 9 April 2016 at 22:43, Victor Stinner <victor.stinner at gmail.com>
wrote:
> > >>>See pysandbox test suite for a lot of ways to escape a sandbox.
CPython has
> > >>>a list of know code to crash CPython (I don't recall the dieectory in
> > >>>sources), even with the latest version of CPython.
> > >>
> > >>They're at https://hg.python.org/cpython/file/tip/Lib/test/crashers
> > >
> > >Thanks. I take your point that sandboxing Python requires CPython to
> > >free of code execution bugs. However I will note that none of the
> > >crashers in that directory will work inside my experiment (except
> > >"infinite_loop_re.py", which isn't a crasher just a long loop).
> >
> > Try following example:
> >
> >     it = iter([1])
> >     for i in range(1000000):
> >         it = filter(None, it)
> >     next(it)
>
> That does indeed segfault. I guess you should report that as a bug!

There will be always be obscure ways to crash the interpreter. That one can
be fixed but if someone really wants to break your sandbox this way then
they will be able to. Remember that exploits are often based on bugs and
any codebase the size of CPython has bugs.

I haven't looked at your sandbox but for a different approach try this one:

  L = [None]
  L.extend(iter(L))

On my Linux machine that doesn't just crash Python.

--
Oscar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160411/8294986b/attachment.html>