Re: Untrusted code execution

On 2016-04-07, Jon Ribbens wrote: > I've put an example script here: > > https://github.com/jribbens/unsafe/blob/master/unsafe.py > > When run as a script, it will execute whatever Python code you pass it > on stdin. > > If anyone can break it (by which I mean

Re: Untrusted code execution

Paul Rubin writes: > Lua is supposed to be easy to embed and sandbox. It might be > interesting to write Python bindings for the Lua interpreter sometime. Isn't this something similar to already existing https://pypi.python.org/pypi/lupa/? ciao, lele. -- nickname:

Re: Untrusted code execution

On Fri, 8 Apr 2016 12:25 am, Jon Ribbens wrote: > On 2016-04-07, Chris Angelico wrote: >> Options 1 and 2 are nastily restricted. Option 3 is likely broken, as >> exception objects carry tracebacks and such. > > Everything you're saying here is assuming that we must not let

Re: Untrusted code execution

On Fri, 8 Apr 2016 01:18 am, Jon Ribbens wrote: > No, actually absolutely no modules at all are safe to import directly. > This is because the untrusted code might alter them Good thinking! I never even thought of that. -- Steven -- https://mail.python.org/mailman/listinfo/python-list

Re: Untrusted code execution

On Thu, Apr 7, 2016 at 11:35 AM, Jon Ribbens wrote: > Well, it entirely depends on how much you're trying to allow the > sandboxed code to do. Most of the stuff in that script (e.g. > _copy_module and safe versions of get/set/delattr, exec, and eval) > I don't think

Re: Untrusted code execution

On 2016-04-07, Chris Angelico wrote: > On Fri, Apr 8, 2016 at 3:20 AM, Jon Ribbens > wrote: >> On 2016-04-07, Random832 wrote: >>> On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote: > All the obvious, and even

Re: Untrusted code execution

On Fri, Apr 8, 2016 at 3:20 AM, Jon Ribbens wrote: > On 2016-04-07, Random832 wrote: >> On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote: >>> > All the obvious, and even not-so-obvious, attack tools are gone: >>> > eval, exec, getattr, type,

Re: Untrusted code execution

On 2016-04-07, Random832 wrote: > On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote: >> > All the obvious, and even not-so-obvious, attack tools are gone: >> > eval, exec, getattr, type, __import__. > > We don't even need to take these away, per se. > > eval and exec could

Re: Untrusted code execution

On Fri, Apr 8, 2016 at 1:18 AM, Jon Ribbens wrote: > No, actually absolutely no modules at all are safe to import directly. > This is because the untrusted code might alter them, and then the > altered code would be used by the trusted main application. Trivial >

Re: Untrusted code execution

On 2016-04-07, Chris Angelico wrote: > On Thu, Apr 7, 2016 at 11:45 AM, Steven D'Aprano wrote: >> And you would have to do something about the unfortunate matter that modules >> have a reference to the unrestricted __builtins__: >> >> py>

Re: Untrusted code execution

On Thu, Apr 7, 2016, at 08:13, Jon Ribbens wrote: > > All the obvious, and even not-so-obvious, attack tools are gone: > > eval, exec, getattr, type, __import__. We don't even need to take these away, per se. eval and exec could be replaced with functions that perform the evaluation with the

Re: Untrusted code execution

On Thu, Apr 7, 2016, at 00:48, Steven D'Aprano wrote: > Sure, but I'm just demonstrating that the unrestricted builtins are just > one > attribute lookup away. And as Chris points out, if you have (say) the os > module, then: > > magic = os.sys.modules[ > ''.join(chr(i-1) for i in >

Re: Untrusted code execution

On 2016-04-07, Chris Angelico wrote: > Options 1 and 2 are nastily restricted. Option 3 is likely broken, as > exception objects carry tracebacks and such. Everything you're saying here is assuming that we must not let the attacker see any exception objects, but I don't

Re: Untrusted code execution

On Thu, Apr 7, 2016 at 10:13 PM, Jon Ribbens wrote: > It's true that I was using eval(), but I don't think that actually > fundamentally changes the game. Almost exactly the same sanitisation > method can be used to make exec() code safe. ("import" for example > does

Re: Untrusted code execution

On 2016-04-06, Steven D'Aprano wrote: > On Wed, 6 Apr 2016 03:48 am, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens >> wrote: >>> The received wisdom is that restricted code execution in Python is >>> an insolubly hard

Re: Untrusted code execution

Jon Ribbens writes: >> That string decodes to "__private". > Yes, and? ... The namespace > I was suggesting didn't provide access to any objects which have a > 'get()' method which would access attributes. I see, I forgot that getattr is a function, not an object

Re: Untrusted code execution

On Thursday 07 April 2016 13:40, Random832 wrote: > On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote: >> And you would have to do something about the unfortunate matter that >> modules >> have a reference to the unrestricted __builtins__: >> >> py> os.__builtins__['eval'] >> > > Well, I

Re: Untrusted code execution

On Wed, Apr 6, 2016, at 21:45, Steven D'Aprano wrote: > And you would have to do something about the unfortunate matter that > modules > have a reference to the unrestricted __builtins__: > > py> os.__builtins__['eval'] > Well, I thought that the solution being discussed uses AST to generally

Re: Untrusted code execution

On Thu, Apr 7, 2016 at 11:45 AM, Steven D'Aprano wrote: > And you would have to do something about the unfortunate matter that modules > have a reference to the unrestricted __builtins__: > > py> os.__builtins__['eval'] > This *in itself* is blocked by the rule against

Re: Untrusted code execution

On Wed, 6 Apr 2016 11:14 pm, Random832 wrote: > On Tue, Apr 5, 2016, at 21:43, Steven D'Aprano wrote: >> As Zooko says, Guido's "best argument is that reducing usability (in >> terms >> of forbidding language features, especially module import) and reducing >> the >> usefulness of extant library

Re: Untrusted code execution

On Wed, Apr 6, 2016, at 12:04, Chris Angelico wrote: > On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly wrote: > > type might also be a concern since it can be used to assemble > > arbitrary classes. > > Sadly, this means denying the ability to interrogate an object for its >

Re: Untrusted code execution

On Wed, Apr 6, 2016 at 10:04 AM, Chris Angelico wrote: > On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly wrote: >> type might also be a concern since it can be used to assemble >> arbitrary classes. > > Sadly, this means denying the ability to interrogate an

Re: Untrusted code execution

On Thu, Apr 7, 2016 at 1:41 AM, Ian Kelly wrote: > type might also be a concern since it can be used to assemble > arbitrary classes. Sadly, this means denying the ability to interrogate an object for its type. And no, this won't do: def safe_type(obj): return type(obj)

Re: Untrusted code execution

On Tue, Apr 5, 2016 at 7:43 PM, Steven D'Aprano wrote: > I think Jon is on the right approach here for restricting evaluation of > evaluation, which is a nicely constrained and small subset of Python. He's > not allowing unrestricted arbitrary code execution: he has a very >

Re: Untrusted code execution

On Tue, Apr 5, 2016, at 21:43, Steven D'Aprano wrote: > As Zooko says, Guido's "best argument is that reducing usability (in > terms > of forbidding language features, especially module import) and reducing > the > usefulness of extant library code" would make the resulting interpreter > too >

Re: Untrusted code execution

On Wed, Apr 6, 2016 at 11:43 AM, Steven D'Aprano wrote: > Look at what you've done: you've restricted the entire world of Python down > to, effectively, a calculator and a few string methods. That's not to say > that a calculator and a few string methods won't be useful to

Re: Untrusted code execution

On Wed, 6 Apr 2016 03:48 am, Chris Angelico wrote: > On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens > wrote: >> The received wisdom is that restricted code execution in Python is >> an insolubly hard problem, but it looks a bit like my 7-line example >> above disproves

Re: Untrusted code execution

On 2016-04-05, Paul Rubin wrote: > Jon Ribbens writes: >>> isinstance(node, ast.Attribute) and node.attr.startswith("_")): >>> raise ValueError("Access to private values is not allowed.") >>> namespace =

Re: Untrusted code execution

Jon Ribbens writes: >> isinstance(node, ast.Attribute) and node.attr.startswith("_")): >> raise ValueError("Access to private values is not allowed.") >> namespace = {"__builtins__": {"int": int, "str": str, "len": len}} > Nobody has

Re: Untrusted code execution

On Wed, Apr 6, 2016 at 4:50 AM, Jon Ribbens wrote: > On 2016-04-05, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens >> wrote: >>> The received wisdom is that restricted code execution in Python is

Re: Untrusted code execution

On 2016-04-05, Jon Ribbens wrote: > On 2016-04-05, Chris Angelico wrote: >> Your code is a *lot* safer for using 'eval' rather than 'exec'. >> Otherwise, you'd be easily exploited using exceptions, which carry a >> ton of info. > > ... but all in

Re: Untrusted code execution

On 2016-04-05, Chris Angelico wrote: > You can also create objects of various types using literal/display > syntax, and that might let you craft some weird construct that > effectively access those attributes without actually having an > attribute that starts with an underscore.

Re: Untrusted code execution

On 2016-04-05, Chris Angelico wrote: > On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens > wrote: >> The received wisdom is that restricted code execution in Python is >> an insolubly hard problem, but it looks a bit like my 7-line example >> above

Re: Untrusted code execution

On Wed, Apr 6, 2016 at 3:52 AM, Ian Kelly wrote: > On Tue, Apr 5, 2016 at 11:48 AM, Chris Angelico wrote: >> Your code is a *lot* safer for using 'eval' rather than 'exec'. >> Otherwise, you'd be easily exploited using exceptions, which carry a >> ton of

Re: Untrusted code execution

On Tue, Apr 5, 2016 at 11:48 AM, Chris Angelico wrote: > Your code is a *lot* safer for using 'eval' rather than 'exec'. > Otherwise, you'd be easily exploited using exceptions, which carry a > ton of info. But even so, I would not bet money (much less the > security of my

Re: Untrusted code execution

On Wed, Apr 6, 2016 at 3:26 AM, Jon Ribbens wrote: > The received wisdom is that restricted code execution in Python is > an insolubly hard problem, but it looks a bit like my 7-line example > above disproves this theory, provided you choose carefully what you >

Re: Untrusted code execution

On 2016-04-05, Chris Angelico wrote: > On Wed, Apr 6, 2016 at 12:50 AM, Ian Kelly wrote: >> Same here, although it looks to me like this approach could work. Or >> I'm just not clever enough to see how it could be exploited. > > Having been bitten in the

Re: Untrusted code execution

On 2016-04-05, Rustom Mody wrote: > On Tuesday, April 5, 2016 at 7:19:39 PM UTC+5:30, Jon Ribbens wrote: >> On 2016-04-03, Jon Ribbens wrote: >> > I'd just like to say up front that this is more of a thought experiment >> > than anything else, I don't have any plans to use

Re: Untrusted code execution

On Wed, Apr 6, 2016 at 12:50 AM, Ian Kelly wrote: > Same here, although it looks to me like this approach could work. Or > I'm just not clever enough to see how it could be exploited. Having been bitten in the past (our test box was compromised by python-list white hats

Re: Untrusted code execution

On Tue, Apr 5, 2016 at 8:17 AM, Rustom Mody wrote: > On Tuesday, April 5, 2016 at 7:19:39 PM UTC+5:30, Jon Ribbens wrote: >> On 2016-04-03, Jon Ribbens wrote: >> > I'd just like to say up front that this is more of a thought experiment >> > than anything else, I don't have

Re: Untrusted code execution

On Tuesday, April 5, 2016 at 7:19:39 PM UTC+5:30, Jon Ribbens wrote: > On 2016-04-03, Jon Ribbens wrote: > > I'd just like to say up front that this is more of a thought experiment > > than anything else, I don't have any plans to use this idea on any > > genuinely untrusted code. Apart from

Re: Untrusted code execution

On 2016-04-03, Jon Ribbens wrote: > I'd just like to say up front that this is more of a thought experiment > than anything else, I don't have any plans to use this idea on any > genuinely untrusted code. Apart from anything else, there's the > denial-of-service

Untrusted code execution

I'd just like to say up front that this is more of a thought experiment than anything else, I don't have any plans to use this idea on any genuinely untrusted code. Apart from anything else, there's the denial-of-service issue. That said, is there any way that the following Python 3.4 code could

[issue16248] Security bug in tkinter allows for untrusted code execution.

: Tkinter messages: 173047 nosy: ramchandra.apte priority: normal severity: normal status: open title: Security bug in tkinter allows for untrusted code execution. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248

[issue16248] Security bug in tkinter allows for untrusted code execution.

Changes by Ramchandra Apte maniandra...@gmail.com: -- type: - security ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248 ___ ___

[issue16248] Security bug in tkinter allows for untrusted code execution.

Ramchandra Apte added the comment: s/tkinter.py/tkinter.__init__ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248 ___ ___ Python-bugs-list

[issue16248] Security bug in tkinter allows for untrusted code execution.

Ramchandra Apte added the comment: In Lib/tkinter/__init__.py:1801 , the readprofile function executes untrusted code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248 ___

[issue16248] Security bug in tkinter allows for untrusted code execution.

Ramchandra Apte added the comment: specifically, when running Python using sudo (not in a root shell), the $HOME variable is preserved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16248

[issue16248] Security bug in tkinter allows for untrusted code execution.

Ramchandra Apte added the comment: I made many mistakes in the original bug report. Here is a fixed one: Because Lib/tkinter/__init__.py:1801 uses exec to execute code from a file, it has a security bug. It searches for the file in the home dir. Apparently, on my system, the $HOME variable is