[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)
rosuav at gmail.com
Tue Apr 12 09:03:11 EDT 2016
On Tue, Apr 12, 2016 at 10:49 PM, Jon Ribbens
<jon+python-dev at unequivocal.co.uk> wrote:
> On Tue, Apr 12, 2016 at 10:45:06PM +1000, Chris Angelico wrote:
>> On Tue, Apr 12, 2016 at 10:42 PM, Jon Ribbens
>> <jon+python-dev at unequivocal.co.uk> wrote:
>> > That's not a vulnerability, and it's something I already explicitly
>> > mentioned - if you can get a function to return an object's __dict__
>> > then you win. The question is: can you do that?
>> The question is, rather: Can you prove that we cannot?
> I refer you to the answer given previously. Can you prove you cannot
I personally cannot, any more than I can prove that SSL is secure or
that my Linux+Apache system doesn't allow remote code execution . I
trust other people to, and then make a value judgement: is it worth
breaking all the web sites that depend on it? (And sometimes the
answer is "yes".)
One of the key differences with scripts in web browsers is that there
*is* no "outer environment" to access. Remember what I said about the
difference between Python-in-Python sandboxing and, say,
Lua-in-Python? One tiny exploit in Python-in-Python and you suddenly
gain access to the entire outer environment, and it's game over. One
tiny exploit in Lua-in-Python and you have whatever that exploit gave
you, nothing more.
In fact, if you're prepared to forfeit almost all of Python's power to
or Lua engine in your Python code. You'll get a comparable expression
evaluator, and most people won't be able to tell the difference.
You've already cut the set of modules down to just cmath, datetime,
math, and re; I suspect re is next on the chopping block (it has a
global cache - if the outer system uses a regular expression more than
once, it would potentially be possible to mess with it in the cache,
and then next time it gets used, the injected code gets run), and
datetime might not be that far behind. And if they do go, all you have
left is a scientific calculator. You can implement that in any
language you like.
 And if anyone mentions PHP, I will set him to work on the hardest
PHP problem I know of - no, not securing it. I mean convincing end
users that it's not necessary. Securing it is trivial by comparison.
More information about the Python-Dev