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 hold
tav tav at 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.
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 I
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
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
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
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
On Feb, 24 2009 at 12:11PM, Antoine Pitrou solip...@pitrou.net wrote:
tav tav at 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
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 this
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
tav t...@espians.com
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
On Tue, Feb 24, 2009 at 3:05 PM, tav t...@espians.com 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
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 trick...
A goal is
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
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
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:
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 approach:
-
On Mon, Feb 23, 2009 at 11:07 PM, tav t...@espians.com 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.
On Tue, Feb 24, 2009 at 6:46 AM, Andrew Dalke da...@dalkescientific.com wrote:
On Tue, Feb 24, 2009 at 3:05 PM, tav t...@espians.com 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
*
On Tue, Feb 24, 2009 at 7:24 AM, Jeff Hall hall.j...@gmail.com 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
On Tue, Feb 24, 2009 at 12:27 AM, tav t...@espians.com 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,
On Tue, Feb 24, 2009 at 6:18 AM, tav t...@espians.com 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/)
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
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.
It
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
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
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
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 Tue, Feb 24, 2009 at 2:18 PM, Heracles
st...@integrityintegrators.net 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.
29 matches
Mail list logo