Escaping a Python sandbox (NdH 2013 quals writeup)

Tl;dr if your code takes user input and interprets it as code, you have an inherently insecure program. Dynamic languages with lots of introspection made their work easier here, but the whole reason it was possible is because the program was intentionally insecure. The "restricted environment" was a few small hacks on top of eval, it wasn't a serious attempt to make it secure.

Based on this exploit if not on general principle, it seems advisable to wrap a sandboxing runtime in additional protections. For example codepad.org says: "When your app is remote code execution, you have to expect security problems. Rather than rely on just the chroot and ptrace supervisor, I've taken some additional precautions: The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections. The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically."

Or create a real sandbox, with interpreter support, like the PyPy one.

From the article:

> You can get the code object of a function using myfunc.func_code. This is forbidden in the restricted mode of the Python interpreter, so we can’t see the code of the auth function.