Challenge: escape from the pysandbox
Victor Stinner
pysandbox is a new Python sandbox project under development. By default,
untrusted code executed in the sandbox cannot modify the environment (write a
file, use print or import a module). But you can configure the sandbox to
choose exactly which features are allowed or not, eg. import sys module and
read the file /etc/issue.
I think that the project reached the "testable" stage. I launch a new
challenge: try to escape from the sandbox. I'm unable to write strict rules.
The goal is to access objects outside the sandbox. Eg. write into a file,
import a module which is not in the whitelist, modify an object outside the
sandbox, etc.
To test the sandbox, you have 3 choices:
- interpreter.py: interactive interpreter executed in the sandbox, use:
--verbose to display the whole sandbox configuration,
--features=help to enable help() function,
--features=regex to enable regex,
--help to display the help.
- execfile.py <your_script.py>: execute your script in the sandbox.
It has also --features option: use --features=stdout to be able
to use the print instruction :-)
- use directly the Sandbox class: use methods call(), execute()
or createCallback()
Don't use "with sandbox: ..." because there is known but with local frame
variables. I think that I will later drop this syntax because of this bug.
Except of debug_sandbox, I consider that all features are safe and so you can
enable all features :-)
There is no prize, it's just for fun! But I will add the name of hackers
founding the best exploits.
pysandbox is not ready for production, it's under heavy development. Anyway I
*hope* that you will quickly find bugs!
--
Use tests.py to found some examples of how you can escape a sandbox. pysandbox
is protected against all methods described in tests.py ;-)
See the README file to get more information about how pysandbox is implemented
and get a list of other Python sandboxes.
pysandbox is currently specific to CPython, and it uses some ugly hacks to
patch CPython in memory. In the worst case it will crash the pysandbox Python
process, that's all. I tested it under Linux with Python 2.5 and 2.6. The
portage to Python3 is not done yet (is someone motivated to write a
patch? :-)).
--
Victor Stinner
http://www.haypocalc.com/
Victor Stinner
> pysandbox is a new Python sandbox project
... I just forget to explain how to download it.
Website: http://github.com/haypo/pysandbox/
Download the repository using git:
git clone git://github.com/haypo/pysandbox.git
or
git clone http://github.com/haypo/pysandbox.git
Or download the .zip or .tar.gz tarball using the "Download source" button on
the website.
Daniel Fetchinson
Out of curiosity, the python sandbox behind google app engine is open source?
If so, how is it different from your project, if not, anyone knows if
it will be in the future?
Cheers,
Daniel
--
Psss, psss, put it down! - http://www.cafepress.com/putitdown
Victor Stinner
> >> pysandbox is a new Python sandbox project
>
> Out of curiosity, the python sandbox behind google app engine is open
> source? If so, how is it different from your project, if not, anyone knows
> if it will be in the future?
I don't know this project. Do you have the URL of the project home page? Is it
the "safelite.py" project?
Daniel Fetchinson
It's google's hosting solution called app engine, for python web
applications: http://code.google.com/appengine/docs/python/gettingstarted/
I guess they also have some kind of a sandbox if they let people run
python on their machines, I'm not sure if it's open source though.
Victor Stinner
> It's google's hosting solution called app engine, for python web
> applications: http://code.google.com/appengine/docs/python/gettingstarted/
>
> I guess they also have some kind of a sandbox if they let people run
> python on their machines, I'm not sure if it's open source though.
Yes, Google AppEngine has its Python sandbox and the source code is available
online. I don't know the license. I found 7 vulnerabilities in 1 hour :-) I
contacted Google security team.
To answer to your question "How is [AppEngine] different from your project?":
* pysanbox has an import whitelist, whereas AppEngine has an import blacklist
(subprocess, socket, ... builtin modules are replaced by safe versions).
Import a Python module written in C is forbidden.
* Import a module in AppEngine imports all symbols, whereas pysandbox uses
also a symbol whitelist.
* AppEngine doesn't have proxies, all objects are modifiable (eg. sys.path)
There are other differences, but I prefer to wait for the answer from Google
before telling you more :)
AppEngine sandbox and pysandbox projects are very close: most protections are
based on blacklists, whereas RestrictedPython is only based on whitelists.
Aahz
Daniel Fetchinson <fetch...@googlemail.com> wrote:
>
>I guess they also have some kind of a sandbox if they let people run
>python on their machines, I'm not sure if it's open source though.
Thing is, I'm sure that Google uses a critical backstop to any
Python-based sandbox: something like a chroot jail. The Python sandbox
is mostly there to inform you about what you can and can't do; the real
security is provided by the OS.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
"Many customs in this life persist because they ease friction and promote
productivity as a result of universal agreement, and whether they are
precisely the optimal choices is much less important." --Henry Spencer
Daniel Fetchinson
>>python on their machines, I'm not sure if it's open source though.
>
> Thing is, I'm sure that Google uses a critical backstop to any
> Python-based sandbox: something like a chroot jail. The Python sandbox
> is mostly there to inform you about what you can and can't do; the real
> security is provided by the OS.
I see, makes perfect sense. This then raises the question whether it's
important to have a 100% fool proof python sandbox without help from
the OS, or this goal is not only too ambitious but also not really a
useful one. One aspect might be that one might want to have a platform
independent way of sandboxing, perhaps.
Victor Stinner
> >>I guess they also have some kind of a sandbox if they let people run
> >>python on their machines, I'm not sure if it's open source though.
> >
> > Thing is, I'm sure that Google uses a critical backstop to any
> > Python-based sandbox: something like a chroot jail. The Python sandbox
> > is mostly there to inform you about what you can and can't do; the real
> > security is provided by the OS.
>
> important to have a 100% fool proof python sandbox without help from
> the OS, or this goal is not only too ambitious but also not really a
> useful one.
This is just impossible :-) PHP tried that but it's too hard to write an
exhaustive blacklist because too much code have to be modified. If you require
a 100% fool proof sandbox, you have to use a sandbox between the Python
process and the OS (and not inside the Python process).
> One aspect might be that one might want to have a platform
> independent way of sandboxing, perhaps.
The problem have to be splitted in two parts: protect access to OS resources
(files, network, etc.) and protect access to Python objects (eg. create a read
only view of objects injected to the sandbox).
An "OS sandbox" can not protect objects inside the Python object. And
pysandbox cannot protect all access to OS resources (but I try to do that
:-)).
pysandbox is a possible solution to the second problem: control Python object
space.
Victor Stinner
> Yes, Google AppEngine has its Python sandbox and the source code is
> available online. I don't know the license. I found 7 vulnerabilities in 1
> differences, but I prefer to wait for the answer from
> Google before telling you more :)
Google answered me. I misunderstood AppEngine sandbox. It's not a Python
sandbox.
AppEngine sandbox is just a tool helping developers to test programs without
the "real" (OS) sandbox. Their Python sandbox *emulates* the real sandbox, and
so it's completly different to pysandbox.
Nobody
>> I see, makes perfect sense. This then raises the question whether it's
>> important to have a 100% fool proof python sandbox without help from
>> the OS, or this goal is not only too ambitious but also not really a
>> useful one.
>
> This is just impossible :-) PHP tried that but it's too hard to write an
> exhaustive blacklist because too much code have to be modified. If you
> require a 100% fool proof sandbox, you have to use a sandbox between the
> Python process and the OS (and not inside the Python process).
It's entirely feasible to implement a perfect sandbox at the language
level. But you have to design this in from the beginning. If you try to
retro-fit it, you end up either failing or with an entirely different
language.
A black-list approach won't work; you have to deny by default then
white-list "safe" functionality.