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

Marcin Kościelnicki koriakin at 0x04.net
Fri Apr 8 11:49:12 EDT 2016

On 08/04/16 16:18, Jon Ribbens wrote:
> I've made another attempt at Python sandboxing, which does something
> which I've not seen tried before - using the 'ast' module to do static
> analysis of the untrusted code before it's executed, to prevent most
> of the sneaky tricks that have been used to break out of past attempts
> at sandboxes.
> In short, I'm turning Python's usual "gentleman's agreement" that you
> should not access names and attributes that are indicated as private
> by starting with an underscore into a rigidly enforced rule: try and
> access anything starting with an underscore and your code will not be
> run.
> Anyway the code is at https://github.com/jribbens/unsafe
> It requires Python 3.4 or later (it could probably be made to work on
> Python 2.7 as well, but it would need some changes).
> I would be very interested to see if anyone can manage to break it.
> Bugs which are trivially fixable are of course welcomed, but the real
> question is: is this approach basically sound, or is it fundamentally
> unworkable?

That one is trivially fixable, but here goes:

async def a():
     global c
     c = b.cr_frame.f_back.f_back.f_back

b = a()

Also, if the point of giving me a subclass of datetime is to prevent 
access to the actual class, that can be circumvented:

 >>> real_datetime = datetime.datetime.mro()[1]
 >>> real_datetime
<class 'datetime.datetime'>

But I'm not sure what good that is.

More information about the Python-Dev mailing list