Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 01:40:57PM +, David Wilson wrote: > On Tue, Apr 12, 2016 at 11:12:27PM +1000, Steven D'Aprano wrote: > > I can think of one possible threat. Suppose that the locale library > > has a bug, so that calling "aardvark".isdigit seg faults, potentially > > executing arbitrary

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 11:12:27PM +1000, Steven D'Aprano wrote: > I can think of one possible threat. Suppose that the locale library > has a bug, so that calling "aardvark".isdigit seg faults, potentially > executing arbitrary C code, but at the very least crashing the > application. Is that

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 11:03:11PM +1000, Chris Angelico wrote: > One of the key differences with scripts in web browsers is that there > *is* no "outer environment" to access. If you think that then I think you considerably misunderstand how modern browsers work. > Remember what I said about

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, 12 Apr 2016, Jon Ribbens wrote: This is still a massive game of whack-a-mole. No, it still isn't. If the names blacklist had to keep being extended then you would be right, but that hasn't happened so far. Whitelists by definition contain only a small, limited number of potential

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 11:12 PM, Steven D'Aprano wrote: > To give a concrete example... suppose that the C locale library is > unsafe. Further, let's suppose that the str.isdigit method calls code > from the C locale library, to determine whether or not the string is > made

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

I haven't been following this thread in detail, so perhaps I have missed something, but I have a question... On Tue, Apr 12, 2016 at 02:05:06PM +0200, Victor Stinner wrote: > You don't understand that even if the visible "Python scope", "Python > namespace", or call it as you want (the code

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 10:49 PM, Jon Ribbens 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 >> wrote: >> > That's not a vulnerability, and it's

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 10:45:06PM +1000, Chris Angelico wrote: > On Tue, Apr 12, 2016 at 10:42 PM, Jon Ribbens > 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

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 02:16:57PM +0200, Victor Stinner wrote: > I read your code and the code of CPython. I found many issues. Thanks for your efforts. > Your "safe import" hides real functions with a proxy. Ok. But the code > of modules is still run in the real namespace, Yes, that was the

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 10:42 PM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 02:31:19PM +0200, Victor Stinner wrote: >> Oh, I forgot to mention another vulnerability: you block access to >> attributes by replacing getattr and by analyzing the AST. Ok, but one

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 02:31:19PM +0200, Victor Stinner wrote: > Oh, I forgot to mention another vulnerability: you block access to > attributes by replacing getattr and by analyzing the AST. Ok, but one > more time, it's not enough. If you get access to obj.__dict__, you > will likely get access

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 02:05:06PM +0200, Victor Stinner wrote: > 2016-04-12 13:10 GMT+02:00 Jon Ribbens : > > No, it's a matter of reducing the whitelist. I must admit that > > I don't understand in what way this is not already clear. Look: > > > > >>>

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-12 14:16 GMT+02:00 Victor Stinner : > I read your code and the code of CPython. I found many issues. > (...) > The exploit is based on two things: > > * update_wrapper() is used to get the secret attribute using the real > getattr() function > * update_wrapper() +

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-12 14:18 GMT+02:00 Jon Ribbens : > The question is: with a minimal (or empty) set of builtins, and a > restriction on ast.Name and ast.Attribute nodes, can exec/eval be > made 'safe' so they cannot execute code outside the sandbox. According to multiple

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-12 13:38 GMT+02:00 Maciej Fijalkowski : > (...) you end up with either a > completely unusable python (the python that can't run anything is > trivially secure) Yeah, that's the obvious question: what's the purpose of such very limited Python subset, for example

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 01:38:09PM +0200, Maciej Fijalkowski wrote: > Jon, let me reiterate. You asked people to break it (that's the title > of the thread) and they did so almost immediately. Then you patched > the thing and asked them to break it again and they did. Now the > faulty assumption

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-08 16:18 GMT+02:00 Jon Ribbens : > I've made another attempt at Python sandboxing, which does something > which I've not seen tried before - using the 'ast' module to do static > analysis of the untrusted code before it's executed, to prevent most > of the

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-12 13:10 GMT+02:00 Jon Ribbens : > No, it's a matter of reducing the whitelist. I must admit that > I don't understand in what way this is not already clear. Look: > > >>> len(unsafe._SAFE_MODULES) > 23 You don't understand that even if the visible

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 9:10 PM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 08:27:14PM +1000, Chris Angelico wrote: >> decimal.getcontext is a simple and obvious example of a way that >> global mutable objects can be accessed across the boundary. There is >> no

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 1:14 PM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 06:21:04AM -0400, Isaac Morland wrote: >> On Tue, 12 Apr 2016, Jon Ribbens wrote: >> >>This is still a massive game of whack-a-mole. >> > >> >No, it still isn't. If the names blacklist

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 06:21:04AM -0400, Isaac Morland wrote: > On Tue, 12 Apr 2016, Jon Ribbens wrote: > >>This is still a massive game of whack-a-mole. > > > >No, it still isn't. If the names blacklist had to keep being extended > >then you would be right, but that hasn't happened so far.

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 08:27:14PM +1000, Chris Angelico wrote: > On Tue, Apr 12, 2016 at 8:06 PM, Jon Ribbens > wrote: > > No, it still isn't. If the names blacklist had to keep being extended > > then you would be right, but that hasn't happened so far.

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 8:06 PM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 06:57:37PM +1000, Chris Angelico wrote: >> The sandbox code assumes that an attacker cannot create files in the >> current directory. > > If the attacker can create such files then the

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 06:57:37PM +1000, Chris Angelico wrote: > And yes, you win if you get another module. Interestingly, you're > allowed to import urllib.parse, but not urllib itself; but "import > urllib.parse" makes urllib available - and, since modules inside > modules are blacklisted,

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 06:28:34PM +1000, Chris Angelico wrote: > On Sat, Apr 9, 2016 at 12:18 AM, Jon Ribbens > wrote: > > Anyway the code is at https://github.com/jribbens/unsafe > > It requires Python 3.4 or later (it could probably be made to work on > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 6:17 PM, Paul Moore wrote: > Well, I'll ask the obvious question, then. In allowing "import" did > you allow "import ctypes"? If so, then I win :-) Or did you explicitly > whitelist certain modules? And if so, which ones are they, and did I > succeed

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sat, Apr 9, 2016 at 12:18 AM, Jon Ribbens wrote: > Anyway the code is at https://github.com/jribbens/unsafe > It requires Python 3.4 or later (it could probably be made to work on > Python 2.7 as well, but it would need some changes). Rather annoying point:

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11 April 2016 at 17:53, Jon Ribbens wrote: >> You're limiting the subset of Python that people can use, >> understood. And you're trying to ensure that people can't do "bad >> things". Again, understood. But what subset are you actually allowing, >> and what

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 8:43 AM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 03:02:54AM +1000, Chris Angelico wrote: >> It all depends on how much functionality you want. If all you need is >> a numeric expression evaluator, that's not too hard - disallow all >>

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 01:08:36PM +1200, Greg Ewing wrote: > Jon Ribbens wrote: > >So far it looks like blocking "_*" and the frame object attributes > >appears to be sufficient. > > Even if your sandbox as it currently exists is secure, it's > only an extremely restricted subset. I'm not sure

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 8:08 PM, Greg Ewing wrote: > Jon Ribbens wrote: > >> So far it looks like blocking "_*" and the frame object attributes >> appears to be sufficient. >> > > Even if your sandbox as it currently exists is secure, it's > only an extremely

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

Jon Ribbens wrote: So far it looks like blocking "_*" and the frame object attributes appears to be sufficient. Even if your sandbox as it currently exists is secure, it's only an extremely restricted subset. You seem to be assuming that if your technique works so far, then it can be extended

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 03:02:54AM +1000, Chris Angelico wrote: > On Tue, Apr 12, 2016 at 2:53 AM, Jon Ribbens > wrote: > > On Mon, Apr 11, 2016 at 04:04:21PM +0100, Paul Moore wrote: > >> However, it's not at all clear (to me at least) what you *are* trying > >>

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

You seem to be defining a (restricted subset of an existing) language; which will need version strings and ABI tags for compatibility purposes: * Build Tags (for Python variants): * https :// www.python.org

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 2:53 AM, Jon Ribbens wrote: > On Mon, Apr 11, 2016 at 04:04:21PM +0100, Paul Moore wrote: >> However, it's not at all clear (to me at least) what you *are* trying >> to do. > > I'm trying to see to what extent we can use ast node

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 04:04:21PM +0100, Paul Moore wrote: > However, it's not at all clear (to me at least) what you *are* trying > to do. I'm trying to see to what extent we can use ast node inspection to remedy the failures of prior attempts at Python sandboxing. Is there *any* extent to

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 08:35:11AM -0700, Nikolaus Rath wrote: > On Apr 11 2016, Jon Ribbens wrote: > >> What I see is that you asked to break your sandbox, and less than 1 > >> hour later, a first vulnerability was found (exec called with two > >> parameters). A

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

Steven D'Aprano: > although I must admit I don't understand why the entire OS is effected. A consequence of memory overcommit, I'd wager. The crasher code not only allocates vast swathes of memory, but accesses it as well, which is bad news for Linux with overcommit enabled. When the OS runs

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 9:04 PM, Isaac Morland wrote: > But I would not use for security purposes a Python sandbox that was not > formally verified to be correct and unbreakable. Of course in order for > this to be possible, there first has to be a formal semantics for

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, 11 Apr 2016, Victor Stinner wrote: 2016-04-10 18:43 GMT+02:00 Jon Ribbens : That's the opposite of my approach though - I'm starting small and adding things, not starting with everything and removing stuff. Even if what we end up with is an extremely

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Apr 11 2016, Jon Ribbens wrote: >> What I see is that you asked to break your sandbox, and less than 1 >> hour later, a first vulnerability was found (exec called with two >> parameters). A few hours later, a second vulnerability was found >> (async generator

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11 April 2016 at 15:46, Jon Ribbens wrote: > It's trying to alter > the global Python environment so that arbitrary code can be executed, > whereas I am not even trying to allow execution of arbitrary code and > am not altering the global environment.

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 11:40:05AM +0200, Victor Stinner wrote: > 2016-04-10 18:43 GMT+02:00 Jon Ribbens : > > That's the opposite of my approach though - I'm starting small and > > adding things, not starting with everything and removing stuff. Even > > if what

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-10 18:43 GMT+02:00 Jon Ribbens : > On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote: >>Please don't loose time trying yet another sandbox inside CPython. It's >>just a waste of time. It's broken by design. >> >>Please read my

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 08:06:34AM +0200, Oleg Broytman wrote: > On Mon, Apr 11, 2016 at 12:42:47AM -0500, Wes Turner > wrote: > > On Sun, Apr 10, 2016 at 10:50 PM, Oleg Broytman wrote: > > > > > On Mon, Apr 11, 2016 at 01:09:19PM +1000,

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11.04.16 00:53, Jon Ribbens wrote: Try following example: it = iter([1]) for i in range(100): it = filter(None, it) next(it) That does indeed segfault. I guess you should report that as a bug! There is old issue that doesn't have adequate solution. And this is

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11 April 2016 at 13:49, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/10/2016 06:31 PM, Jon Ribbens wrote: >> Unless someone knows a way to get to an object's __dict__ or its type >> without using vars() or type() or underscore

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 12:42:47AM -0500, Wes Turner wrote: > On Sun, Apr 10, 2016 at 10:50 PM, Oleg Broytman wrote: > > > On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano < > > st...@pearwood.info> wrote: > > > On Sun, Apr 10, 2016 at 08:12:30PM

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 10:50 PM, Oleg Broytman wrote: > On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano < > st...@pearwood.info> wrote: > > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano wrote: > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > wrote: > > > I haven't looked at your sandbox but for a

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > wrote: > > I haven't looked at your sandbox but for a different approach try this one: > > > > L = [None] > > L.extend(iter(L)) > > > > On my Linux

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/10/2016 06:31 PM, Jon Ribbens wrote: > Unless someone knows a way to get to an object's __dict__ or its type > without using vars() or type() or underscore attributes... Hmm, 'classmethod'-wrapped functions get passed the type. Tres. - --

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin wrote: > I haven't looked at your sandbox but for a different approach try this one: > > L = [None] > L.extend(iter(L)) > > On my Linux machine that doesn't just crash Python. For the record: don't try this if you

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 10 Apr 2016 22:55, "Jon Ribbens" wrote: > > On Mon, Apr 11, 2016 at 12:07:48AM +0300, Serhiy Storchaka wrote: > > On 10.04.16 19:51, Jon Ribbens wrote: > > >On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > > >>On 9 April 2016 at 22:43, Victor

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 02:08:16PM -0700, Nikolaus Rath wrote: > On Apr 10 2016, Jon Ribbens wrote: > > On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote: > > That's the opposite of my approach though - I'm starting small and > > adding things, not

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 12:07:48AM +0300, Serhiy Storchaka wrote: > On 10.04.16 19:51, Jon Ribbens wrote: > >On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > >>On 9 April 2016 at 22:43, Victor Stinner wrote: > >>>See pysandbox test suite for a lot of ways

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Apr 10 2016, Jon Ribbens wrote: > On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote: >>Please don't loose time trying yet another sandbox inside CPython. It's >>just a waste of time. It's broken by design. >> >>Please read my email

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 10.04.16 19:51, Jon Ribbens wrote: On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: On 9 April 2016 at 22:43, Victor Stinner wrote: See pysandbox test suite for a lot of ways to escape a sandbox. CPython has a list of know code to crash CPython (I

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Apr 10, 2016 11:51 AM, "Jon Ribbens" wrote: > > On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > > On 9 April 2016 at 22:43, Victor Stinner wrote: > > > See pysandbox test suite for a lot of ways to escape a sandbox.

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > On 9 April 2016 at 22:43, Victor Stinner wrote: > > See pysandbox test suite for a lot of ways to escape a sandbox. CPython has > > a list of know code to crash CPython (I don't recall the dieectory in > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote: >Please don't loose time trying yet another sandbox inside CPython. It's >just a waste of time. It's broken by design. > >Please read my email about my attempt (pysandbox): >https://lwn.net/Articles/574323/ > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 9 April 2016 at 22:43, Victor Stinner wrote: > Please don't loose time trying yet another sandbox inside CPython. It's just > a waste of time. It's broken by design. > > Please read my email about my attempt (pysandbox): > https://lwn.net/Articles/574323/ > > And the

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

I'm with Victor here. In fact I tried (and failed) to convince Victor that the approach is entirely unworkable when he was starting, don't be the next one :-) On Sat, Apr 9, 2016 at 3:43 PM, Victor Stinner wrote: > Please don't loose time trying yet another sandbox

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

Please don't loose time trying yet another sandbox inside CPython. It's just a waste of time. It's broken by design. Please read my email about my attempt (pysandbox): https://lwn.net/Articles/574323/ And the LWN article: https://lwn.net/Articles/574215/ There are a lot of safe ways to run

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sat, Apr 09, 2016 at 02:20:49AM +1000, Chris Angelico wrote: > On Sat, Apr 9, 2016 at 12:18 AM, Jon Ribbens > wrote: > > Anyway the code is at https://github.com/jribbens/unsafe > > It requires Python 3.4 or later (it could probably be made to work on > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Fri, Apr 08, 2016 at 05:49:12PM +0200, Marcin Kościelnicki wrote: > On 08/04/16 16:18, Jon Ribbens wrote: > That one is trivially fixable, but here goes: > > async def a(): > global c > c = b.cr_frame.f_back.f_back.f_back > > b = a() > b.send(None) > c.f_builtins['print']('broken')

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sat, Apr 9, 2016 at 12:18 AM, Jon Ribbens wrote: > Anyway the code is at https://github.com/jribbens/unsafe > It requires Python 3.4 or later (it could probably be made to work on > Python 2.7 as well, but it would need some changes). Not being a security

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 08/04/16 16:18, Jon Ribbens wrote: I've made another attempt at Python sandboxing, which does something which I've not seen tried before - using the 'ast' module to do static analysis of the untrusted code before it's executed, to prevent most of the sneaky tricks that have been used to break

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Fri, Apr 08, 2016 at 05:21:38PM +0200, Arthur Darcet wrote: >If i'm not mistaken, this breaks out: >> exec('open("out", "w").write("a")', {}) >because if the second argument of exec does not contain a __builtins__ >key, then a copy of the original builtins module is inserted: >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 8 April 2016 at 16:18, Jon Ribbens wrote: > I've made another attempt at Python sandboxing, which does something > which I've not seen tried before - using the 'ast' module to do static > analysis of the untrusted code before it's executed, to prevent most >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Fri, Apr 08, 2016 at 03:37:45PM +0100, Paul Moore wrote: > On 8 April 2016 at 15:18, Jon Ribbens > wrote: > > I would be very interested to see if anyone can manage to break it. > > Bugs which are trivially fixable are of course welcomed, but the real > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 8 April 2016 at 15:18, Jon Ribbens wrote: > I would be very interested to see if anyone can manage to break it. > Bugs which are trivially fixable are of course welcomed, but the real > question is: is this approach basically sound, or is it fundamentally >

[Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

I've made another attempt at Python sandboxing, which does something which I've not seen tried before - using the 'ast' module to do static analysis of the untrusted code before it's executed, to prevent most of the sneaky tricks that have been used to break out of past attempts at sandboxes. In