On Tue, Feb 24, 2009 at 2:18 PM, Heracles
wrote:
>
> Hello,
>
> I am working on a patch to add to the _cursesmodule.c file of the Python
> core libraries. I figured I would take on one of the implemented functions
> to try to get my feet wet contributing to the project. At any rate, I have
> the
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
Hello,
I am working on a patch to add to the _cursesmodule.c file of the Python
core libraries. I figured I would take on one of the implemented functions
to try to get my feet wet contributing to the project. At any rate, I have
the following function defined in the 2.7.a version updated from
This looks very interesting. What I like about Tav's approach is that it
should also be directly applicable to Jython. Much like Jython in general,
there's a tight correspondence between typeobject.c/PyType.java and
genobject.c/PyGenerator.java. So we plan on trying out a similar, presumably
small
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.
If you plan to attend go to
http://us.pycon.org/2009/sprints/projects/python-core/ and fill in your name
and when you plan to be there (not required, though; just nice).
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mail
On Tue, Feb 24, 2009 at 6:18 AM, tav wrote:
> Ehm, I'd strongly discourage any approaches using proxies. The
> performance penalties will just be insane.
And yet your FileReader is essentially a proxy?!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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
Victor Stinner wrote:
> This approach was implemented in PyPy using two interpreters.
>
> In CPython, we may use proxies on anything to check all operations.
> jail -- validations --> real world
> jail <-- proxy objects -- real world
>
> tav's jail might be converted to the whitelist appro
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 Victor,
> Today it's clear that tav's jail is broken.
Forgive me as I'm sleep deprived, but no =)
> Many hackers proved how to break it.
> Fixing each hole is maybe not the good solution.
The aim of this challenge has been to:
1. Validate the functions-based approach
2. Verify if the propo
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
Victor Stinner wrote:
> My approach is maybe naive and imposible to implement :-)
It actually goes back to some of the stuff Brett Cannon was working on
in his object capabilities branch. However, one of the key building
blocks turned out to be an easier to tailor import system, so the
project was
Hi,
Today it's clear that tav's jail is broken. Many hackers proved how to break
it. Fixing each hole is maybe not the good solution.
IMHO the problem is that tav choosed the blacklist approach: hide some "evil"
attributes/functions and hope that the other are safe... which is wrong (eg.
evil
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
30 matches
Mail list logo
