Guido van Rossum wrote:
On Mon, Feb 23, 2009 at 3:16 PM, "Martin v. Löwis" wrote:
Don't I remember the previous restricted module dying a similar "death
of 1,000 cuts" before it was concluded to be unsafe at any height and
abandoned?
I think you are slightly misremembering. It got cu
Lie Ryan wrote:
> On Mon, 23 Feb 2009 23:22:19 +, tav wrote:
>
>> Steve, this isn't death by a 1,000 cuts. What's being put forward here
>> is not a specific implementation -- but rather a specific model of
>> security (the object capability model) -- which has been proven to be
>> foolproof.
On Mon, 23 Feb 2009 23:22:19 +, tav wrote:
> Steve, this isn't death by a 1,000 cuts. What's being put forward here
> is not a specific implementation -- but rather a specific model of
> security (the object capability model) -- which has been proven to be
> foolproof.
Proven? Isn't it imposs
print '''
tav wrote:
> Daniel emailed in the exploit below and it is pretty devastating. It
> takes advantage of the fact that the warnings framework in 2.6+
> dynamically imports modules without being explicitly called!!
Here's one I couldn't develop to a working exploit, but think is promising.
On Tue, Feb 24, 2009 at 12:27 AM, tav wrote:
> Daniel emailed in the exploit below and it is pretty devastating. It
> takes advantage of the fact that the warnings framework in 2.6+
> dynamically imports modules without being explicitly called!!
>
> I've fixed this hole in safelite.py, but would b
On Tue, Feb 24, 2009 at 7:24 AM, Jeff Hall wrote:
> I didn't see Tav actually say this but are we all agreed that compile()
> should be removed from __builtins__?
I personally disagree -- I think we should instead add restrictions on
the creation of new code objects by calling the constructor dir
On Tue, Feb 24, 2009 at 6:46 AM, Andrew Dalke wrote:
> On Tue, Feb 24, 2009 at 3:05 PM, tav wrote:
>> And instead of trying to make tb_frame go away, I'd like to add the
>> following to my proposed patch of RESTRICTED attributes:
>>
>> * f_code
>> * f_builtins
>> * f_globals
>> * f_locals
>>
>> T
On Mon, Feb 23, 2009 at 11:07 PM, tav wrote:
> guido> I can access the various class and metaclass objects
> guido> easily [snip]
>
> It would've been possible to replace __call__ on the metaclass --
> which, though not a security leak by itself, could've been abused for
> some fun.
>
> I've inl
I didn't see Tav actually say this but are we all agreed that compile()
should be removed from __builtins__?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
At 03:52 PM 2/24/2009 +0100, Victor Stinner wrote:
Le Tuesday 24 February 2009 15:46:04 Andrew Dalke, vous avez écrit :
> A goal is to use this in App Engine, yes? Which uses cgitb to report
> errors? Which needs these restricted frame attributes to report the
> values of variables when the error
Hey Andrew & Victor,
tav> But the challenge was about doing `from safelite import FileReader`.
Andrew> Though it doesn't say so on the first post on this thread
Andrew> nor your page at
Andrew> http://tav.espians.com/a-challenge-to-break-python-security.html
Sorry, perhaps I should have
Le Tuesday 24 February 2009 15:46:04 Andrew Dalke, vous avez écrit :
> > And instead of trying to make tb_frame go away, I'd like to add the
> > following to my proposed patch of RESTRICTED attributes:
> >
> > * f_code
> > * f_builtins
> > * f_globals
> > * f_locals
> >
> > That seems to do the tri
On Tue, Feb 24, 2009 at 3:05 PM, tav wrote:
> And instead of trying to make tb_frame go away, I'd like to add the
> following to my proposed patch of RESTRICTED attributes:
>
> * f_code
> * f_builtins
> * f_globals
> * f_locals
>
> That seems to do the trick...
A goal is to use this in App Engine
tav
> But the challenge was about doing `from safelite import FileReader`.
Though it doesn't say so on the first post on this thread nor your page at
http://tav.espians.com/a-challenge-to-break-python-security.html
It says "Now find a way to write to the filesystem from your
interpreter". Whic
Hey Nick,
> Given the context manager hack I just sent you (similar in spirit to
> Paul's, just using a context manager's __exit__() method to get hold of
> the traceback instead of hacked bytecode)
Thanks for this -- very cool!
> I think we can safely say that tb_frame has to go.
I've fixed th
On Feb, 24 2009 at 12:11PM, Antoine Pitrou wrote:
> tav espians.com> writes:
>>
>> I've fixed this hole in safelite.py, but would be interested to know
>> if there are other non-user-initiated dynamically imported modules?
>
> You'd better make __builtins__ read-only, it will plug a whole class
antoine> You'd better make __builtins__ read-only, it will
antoine> plug a whole class of attacks like this.
I tried to put this off as long as I could to try and unearth
interesting attacks.
But unfortunately I couldn't figure out a way to fix the warnings
approach used by Daniel without doi
Another hole. Not as devious as some, but easy to fix with yet another
type check.
This trick notices 'buffering' is passed to open, which does an int
coerce of non-int objects. I can look up the stack frames and get
"open_file", which I can then use for whatever I want.
In this case, I used the
Another hole. Not as devious as some, but easy to fix with yet another
type check. And probably you want to get rid of "get_frame" from
safelite.
This trick notices 'buffering' is passed to open, which does an int
coerce of non-int objects. I can look up the stack frames and get
"open_file", which
tav espians.com> writes:
>
> I've fixed this hole in safelite.py, but would be interested to know
> if there are other non-user-initiated dynamically imported modules?
You'd better make __builtins__ read-only, it will plug a whole class of attacks
like this.
___
tav wrote:
> 1. Remove ``compile`` from the safe builtins
> 2. Take out ``tb_frame``
>
> Thoughts on which of the two options is better would be very appreciated!
Given the context manager hack I just sent you (similar in spirit to
Paul's, just using a context manager's __exit__() method to get h
Daniel emailed in the exploit below and it is pretty devastating. It
takes advantage of the fact that the warnings framework in 2.6+
dynamically imports modules without being explicitly called!!
I've fixed this hole in safelite.py, but would be interested to know
if there are other non-user-initia
guido> I can access the various class and metaclass objects
guido> easily [snip]
It would've been possible to replace __call__ on the metaclass --
which, though not a security leak by itself, could've been abused for
some fun.
I've inlined the __metaclass__ to prevent fun of this kind.
But t
Another potential avenue for attacks:
I can access the various class and metaclass objects easily:
>>> f = FileReader('/etc/passwd')
>>> f.__class__
>>> f.__class__.__metaclass__
>>> f.__class__.__metaclass__.__call__
>>> f.__class__.__metaclass__.__call__.im_func
>>> kall = f.__class__.__met
victor> f.tell.__getattribute__('func_closure')
tak> But, have you actually run that code?
Ooops, I modified my local copy of safelite.py to disable func_xxx
protections :-p With the latest version of safelite.py, my exploit doesn't
work anymore. Sorry.
--
Victor Stinner aka haypo
http://www.
Le Tuesday 24 February 2009 01:31:55 Victor Stinner, vous avez écrit :
> (...)
> But how can we get the closure if b.func_closure doesn't exist? Oh, wait!
> What's this: b.__getattribute__...
> -
> secret = get_cell_value(b.__getattribute__('func_closure')[0])
>
Hey Victor,
You definitely got to the heart of the challenge.
> f.tell.__getattribute__('func_closure')
But, have you actually run that code?
Cos that doesn't work here... sorry if I missed something...
--
love, tav
plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espian
Le Monday 23 February 2009 23:41:30, vous avez écrit :
> http://tav.espians.com/a-challenge-to-break-python-security.html
>
> Please blog/retweet and of course, try the challenge yourselves =)
The challenge can be seen as: is it possible to read "secret" in the following
code without using b.func
tav wrote:
But that doesn't invalidate
the model or the possibility of using it in Python.
However, there's also the matter of whether it's
*practical* to use the model in Python.
The custom-string exploit illustrates that you have
to be extremely careful what you do with, and
what you assume
Le Tuesday 24 February 2009 00:22:19 tav, vous avez écrit :
> guido> >>> class S(str):
> guido> ... def __eq__(self, o): print o; return 'r' == o
> guido> [snip]
>
> Very devious -- @eichin and Guido!
mode = str(mode) is not enough to protect FileReader about evil object
faking "r" string
On Mon, Feb 23, 2009 at 3:16 PM, "Martin v. Löwis" wrote:
>> Don't I remember the previous restricted module dying a similar "death
>> of 1,000 cuts" before it was concluded to be unsafe at any height and
>> abandoned?
>
> I think you are slightly misremembering. It got cut again and again,
> but
guido> >>> class S(str):
guido> ... def __eq__(self, o): print o; return 'r' == o
guido> [snip]
Very devious -- @eichin and Guido!
You guys get the price for the cutest exploit yet -- but sadly no
dinner or drinks -- that was just for the first crack -- which goes to
Victor =)
steve> D
> Don't I remember the previous restricted module dying a similar "death
> of 1,000 cuts" before it was concluded to be unsafe at any height and
> abandoned?
I think you are slightly misremembering. It got cut again and again,
but never died. Then, new-style classes hit an artery, and it bled
to d
Sorry, it wasn't Ian Bicking. I have no idea what made me thing that.
I guess I am not yet an experienced Tweeter. :-( It was Mark Eichin,
CC'ed here.
--Guido
On Mon, Feb 23, 2009 at 2:51 PM, Guido van Rossum wrote:
> TWIW, on Twitter, Ian Bicking just came up with a half-solution. I
> figured o
Don't I remember the previous restricted module dying a similar "death
of 1,000 cuts" before it was concluded to be unsafe at any height and
abandoned?
regards
Steve
Guido van Rossum wrote:
> TWIW, on Twitter, Ian Bicking just came up with a half-solution. I
> figured out the other half. I guess
TWIW, on Twitter, Ian Bicking just came up with a half-solution. I
figured out the other half. I guess you own Ian drinks and me dinner.
:-)
$ python
Python 2.5.3a0 (release25-maint:64494, Jun 23 2008, 19:17:09)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "
> I take it back, we need to find all the trivial ones too.
Agreed!
> BTW Tav, you ought to create a small website for this challenge. A
> blog post or wiki page would suffice.
Done.
http://tav.espians.com/a-challenge-to-break-python-security.html
Please blog/retweet and of course, try the cha
37 matches
Mail list logo
