[Python-Dev] Challenge: Please break this! (was: Reviving restricted mode)

Farshid Lashkari flashk at gmail.com
Tue Feb 24 00:51:25 CET 2009


It seems like some code in safelite passes a file object to
isinstance. By overriding the builtin isinstance function I can get
access to the original file object and create a new one. Here is the
code I used:

from safelite import FileReader

_real_file = None

def _new_isinstance(obj,types):
    global _real_file
    if _real_file is None and obj.__class__.__name__ == 'file':
        _real_file = obj.__class__
    return _old_isinstance(obj,types)

_old_isinstance = __builtins__.isinstance
__builtins__.isinstance = _new_isinstance

FileReader('nul')

f = _real_file('foo.txt','w')
f.write('hello')
f.close()

-Farshid


On Mon, Feb 23, 2009 at 12:10 PM, tav <tav at espians.com> wrote:
> Hey all,
>
> As an attempt to convince everyone of the merits of my functions-based
> approach to security, I've come up with a simple challenge. I've
> attached it as safelite.py
>
> The challenge is simple:
>
> * Open a fresh Python interpreter
> * Do: >>> from safelite import FileReader
> * You can use FileReader to read files on your filesystem
> * Now find a way to *write* to the filesystem from your interpreter
>
> Please note that the aim of this isn't to protect Python against
> crashes/segfaults or exhaustion of resources attacks, so those don't
> count.
>
> I'm keen to know your experiences even if you don't manage to write to
> the filesystem -- and especially if you do!
>
> Dinner and drinks on me for an evening -- when you are next in London
> or I am in your town -- to the first person who manages to break
> safelite.py and write to the filesystem.
>
> Good luck and thanks! =)
>
>> If you block __closure__ and __globals__ on function objects you will get a
>> semblance of a private namespace. That way you might (I have not thought
>> this one through like securing the interpreter for embedding) be able to get
>> what you need to safely pass in Python code through the globals of the code
>> being executed.
>
> Brett, this is exactly what I do. You also need to restrict func_code.
> The patch is simply for closing the other loopholes:
> type.__subclasses__, GeneratorType.gi_frame and gi_code. All possible
> in a patch of 6 lines of code thanks to Python's existing restricted
> framework in the interpreter.
>
> Please review and accept =)
>
> * http://codereview.appspot.com/20051
> * http://codereview.appspot.com/21051
>
> Thanks!
>
> --
> love, tav
>
> plex:espians/tav | tav at espians.com | +44 (0) 7809 569 369
> http://tav.espians.com | @tav | skype:tavespian
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/flashk%40gmail.com
>
>


More information about the Python-Dev mailing list