Le samedi 18 septembre 2010 10:24:49, Greg Ewing a écrit :
> Victor Stinner wrote:
> > I'm still developing irregulary my sandbox project since last june.
> >
> > Today, the biggest problem is the creation of a read only view of the
> > __builtins__ dictionary.
>
> Why do you think you need to do this? What form of attack
> would a writable __builtins__ expose you to that would be
> prevented by making it read-only?
Replace builtin functions make it possible to modify (indirectly) functions
outside the sandbox. Eg. one of the most important function of pysandbox is
proxy() (a function to create a read only view of a object outside the
sandbox, especially on an import), if you replace isinstance() by a function
which always return True: you can get unmodified objects (read+write access).
So it's possible to get the real file type from sys.stdout and so open a new
file.
The example on a modified version of pysandbox (to get the vulnerability):
sandbox>>> __builtins__['isinstance']=lambda obj, cls: True
sandbox>>> import sys
sandbox>>> type(sys.stdout)('/etc/issue').read()
'Debian GNU/Linux squeeze/sid \\n \\l\n\n'
---
It would be possible to create a local copy of each builtin in all pysandbox
functions, but it doesn't protect functions outside pysandbox.
--
Victor Stinner
http://www.haypocalc.com/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4