Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #106410 > unrolled thread

Untrusted code execution

Back to article view | Back to comp.lang.python

Contents

  Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-03 21:12 +0000
    Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 13:46 +0000
      Re: Untrusted code execution Rustom Mody <rustompmody@gmail.com> - 2016-04-05 07:17 -0700
        Re: Untrusted code execution Ian Kelly <ian.g.kelly@gmail.com> - 2016-04-05 08:50 -0600
        Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 17:26 +0000
          Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 18:50 +0000
            Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 19:14 +0000
          Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 19:13 +0000
          Re: Untrusted code execution Steven D'Aprano <steve@pearwood.info> - 2016-04-06 11:43 +1000
            Re: Untrusted code execution Random832 <random832@fastmail.com> - 2016-04-06 09:14 -0400
              Re: Untrusted code execution Steven D'Aprano <steve@pearwood.info> - 2016-04-07 11:45 +1000
                Re: Untrusted code execution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-04-07 14:48 +1000
                Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-07 15:18 +0000
                  Re: Untrusted code execution Steven D'Aprano <steve@pearwood.info> - 2016-04-08 15:28 +1000
            Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-07 12:13 +0000
              Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-07 14:25 +0000
                Re: Untrusted code execution Steven D'Aprano <steve@pearwood.info> - 2016-04-08 15:26 +1000
              Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-07 17:20 +0000
                Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-07 17:35 +0000
                Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-10 17:06 +0000
        Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 17:40 +0000
      Re: Untrusted code execution Paul Rubin <no.email@nospam.invalid> - 2016-04-05 13:39 -0700
        Re: Untrusted code execution Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-04-05 21:13 +0000
          Re: Untrusted code execution Paul Rubin <no.email@nospam.invalid> - 2016-04-07 00:08 -0700
            Re: Untrusted code execution Lele Gaifax <lele@metapensiero.it> - 2016-04-08 10:10 +0200

Page 2 of 2 — ← Prev page 1 [2]

#106535

On 2016-04-05, Chris Angelico <rosuav@gmail.com> wrote:
> On Wed, Apr 6, 2016 at 12:50 AM, Ian Kelly <ian.g.kelly@gmail.com> 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 within 20 minutes of the invitation being sent
> out), I would go with the second of your options. Nearly anything is
> vulnerable if it's permitted to execute arbitrary code; all it takes
> is a sufficiently smart operator.

I am inviting sufficiently smart operators to demonstrate the flaw in
my suggested code ;-)

[toc] | [prev] | [next] | [standalone]

#106543

Jon Ribbens <jon+usenet@unequivocal.co.uk> 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 any thoughts on this at all?

What happens with foo.get("5F5F70726976617465".decode("hex")) ?
That string decodes to "__private".

The Bastion module was removed some time ago because every attempt to do
something like this has failed...

[toc] | [prev] | [next] | [standalone]

#106545

On 2016-04-05, Paul Rubin <no.email@nospam.invalid> wrote:
> Jon Ribbens <jon+usenet@unequivocal.co.uk> 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 any thoughts on this at all?
>
> What happens with foo.get("5F5F70726976617465".decode("hex")) ?
> That string decodes to "__private".

Yes, and? My code wasn't trying to prevent anyone building a string
object starting with an underline, merely to prevent anyone accessing
identifiers and attributes that start with an underline. The namespace
I was suggesting didn't provide access to any objects which have a
'get()' method which would access attributes.

> The Bastion module was removed some time ago because every attempt
> to do something like this has failed...

Bastion was removed because rexec was removed. rexec was very
ambitious - it was trying to allow completely arbitrary Python code
to run in a restricted namespace. That's basically impossible since
Python 2.2.

My method is doing something different - it's inspecting the code
before it's run, to prevent the methods by which people would easily
escape rexec's environment.

Originally, rexec existed and was thought to be 'safe'. Then the
new-style classes were added in Python 2.2, which made rexec unsafe,
so it was disabled because there was no easy way to fix it. Then
in Python 2.5 the new AST parser was added, which I think perhaps
does provide a way to fix rexec (or at least something rexec-like),
but nobody was clamoring for rexec to be reinstated so nobody looked
into what ast could do for rexec.

... unless I'm missing something obvious (or subtle!)

[toc] | [prev] | [next] | [standalone]

#106618

Jon Ribbens <jon+usenet@unequivocal.co.uk> 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 method.
Though, now you've got the problem that there isn't enough capability
left to do much interesting.  I used web.py for a while, that had a
complete interpeter for a sandboxed Python-like language written in
Python itself.  That's a brutal way to deal with the problem, and it had
annoyances, but it seemed to work.  You presumably also want to limit
CPU usage etc.  

Geordi (the C++ irc bot) now just launches the user script in a Docker
container, I think.  Before that it had some fancier sandboxing
approaches.

Lua is supposed to be easy to embed and sandbox.  It might be
interesting to write Python bindings for the Lua interpreter sometime.

[toc] | [prev] | [next] | [standalone]

#106664

Paul Rubin <no.email@nospam.invalid> 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: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
lele@metapensiero.it  |                 -- Fortunato Depero, 1929.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web