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

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

Yet another attempt at a safe eval() call

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

Contents

  Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-03 23:25 +0000
    Re: Yet another attempt at a safe eval() call Tim Chase <python.list@tim.thechases.com> - 2013-01-03 19:11 -0600
      Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 02:34 +0000
    Re: Yet another attempt at a safe eval() call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-04 07:47 +0000
      Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 15:53 +0000
        Re: Yet another attempt at a safe eval() call Michael Torrie <torriem@gmail.com> - 2013-01-04 09:05 -0700
          Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 16:16 +0000
        Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-05 15:56 +0000
          Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-06 15:12 +0000
            Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-07 00:08 +0000
        Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-06 03:01 +1100
        Re: Yet another attempt at a safe eval() call Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2013-01-05 16:17 +0000
          Re: Yet another attempt at a safe eval() call matt.newville@gmail.com - 2013-01-05 08:40 -0800
          Re: Yet another attempt at a safe eval() call matt.newville@gmail.com - 2013-01-05 08:40 -0800
      Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 16:38 +0000
        Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 03:51 +1100
          Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 17:14 +0000
            Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 04:21 +1100
              Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 18:09 +0000
                Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 05:23 +1100
                  Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 18:43 +0000
                    Re: Yet another attempt at a safe eval() call Chris Angelico <rosuav@gmail.com> - 2013-01-05 06:02 +1100
    Re: Yet another attempt at a safe eval() call Chris Rebert <clp2@rebertia.com> - 2013-01-03 23:50 -0800
    Re: Yet another attempt at a safe eval() call Terry Reedy <tjreedy@udel.edu> - 2013-01-04 07:24 -0500
      Re: Yet another attempt at a safe eval() call Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-01-04 13:33 +0000
        Re: Yet another attempt at a safe eval() call Grant Edwards <invalid@invalid.invalid> - 2013-01-04 15:59 +0000
        Re: Yet another attempt at a safe eval() call Alister <alister.ware@ntlworld.com> - 2013-01-04 18:13 +0000

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

#36130

On 2013-01-04, Chris Angelico <rosuav@gmail.com> wrote:
> On Sat, Jan 5, 2013 at 5:09 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>> The error messages are still pretty cryptic, so improving
>> that will add a few more lines.  One nice thing about the ast code is
>> that it's simple to add code to allow C-like character constants such
>> that ('A' === 0x41).  Here's the first pass at ast-based code:
>
> Looks cool, and fairly neat! Now I wonder, is it possible to use that
> to create new operators, such as the letter d? Binary operator, takes
> two integers...

I don't think you can define new operators.  AFAICT, the
lexing/parsing is done using the built-in Python grammar. You can
control the behavior of the predefined operators and reject operators
you don't like, but you can't add new ones or change precedence/syntax
or anything like that.

If you want to tweak the grammar itself, then I think you need to use
something like pyparsing.

-- 
Grant Edwards               grant.b.edwards        Yow! I own seven-eighths of
                                  at               all the artists in downtown
                              gmail.com            Burbank!

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

#36134

On Sat, Jan 5, 2013 at 5:43 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2013-01-04, Chris Angelico <rosuav@gmail.com> wrote:
>> On Sat, Jan 5, 2013 at 5:09 AM, Grant Edwards <invalid@invalid.invalid> wrote:
>>> The error messages are still pretty cryptic, so improving
>>> that will add a few more lines.  One nice thing about the ast code is
>>> that it's simple to add code to allow C-like character constants such
>>> that ('A' === 0x41).  Here's the first pass at ast-based code:
>>
>> Looks cool, and fairly neat! Now I wonder, is it possible to use that
>> to create new operators, such as the letter d? Binary operator, takes
>> two integers...
>
> I don't think you can define new operators.  AFAICT, the
> lexing/parsing is done using the built-in Python grammar. You can
> control the behavior of the predefined operators and reject operators
> you don't like, but you can't add new ones or change precedence/syntax
> or anything like that.
>
> If you want to tweak the grammar itself, then I think you need to use
> something like pyparsing.

Oh well, hehe. I've not seen any simple parsers that let you
incorporate D&D-style dice notation ("2d6" means "roll two 6-sided
dice and sum the rolls" - "d6" implies "1d6").

ChrisA

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

#36102

On Thu, Jan 3, 2013 at 3:25 PM, Grant Edwards <invalid@invalid.invalid> wrote:
>
> I've written a small assembler in Python 2.[67], and it needs to
> evaluate integer-valued arithmetic expressions in the context of a
> symbol table that defines integer values for a set of names.  The
> "right" thing is probably an expression parser/evaluator using ast,
> but it looked like that would take more code that the rest of the
> assembler combined, and I've got other higher-priority tasks to get
> back to.
>
> How badly am I deluding myself with the code below?

Given http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html
and similar, I suspect the answer is "a fair bit".

> def lessDangerousEval(expr):
>     global symbolTable
>     if 'import' in expr:
>         raise ParseError("operand expressions are not allowed to contain the string 'import'")
>     globals = {'__builtins__': None}
>     locals  = symbolTable
>     return eval(expr, globals, locals)
>
> I can guarantee that symbolTable is a dict that maps a set of string
> symbol names to integer values.

Using the aformentioned article as a basis, I was able to get this
doozy working, albeit under Python 3:

$ python3
Python 3.3.0 (default, Nov  4 2012, 17:47:16)
[GCC 4.2.1 Compatible Apple Clang 4.0 ((tags/Apple/clang-421.0.57))] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> expr = "[klass for klass in ().__class__.__bases__[0].__subclasses__() if klass.__name__ == 'Codec'][0].encode.__globals__['__builtins__']['__im'+'port__']('os').remove"
>>> eval(expr, {'__builtins__': None}, {})
<built-in function remove>
>>>

Since the original attack was itself devised against Python 2.x, it's
highly likely that similar convoluted attacks against 2.x remain
possible, unless perhaps you were use a modified interpreter.

Cheers,
Chris

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

#36105

On 1/3/2013 6:25 PM, Grant Edwards wrote:
>
> I've written a small assembler in Python 2.[67], and it needs to
> evaluate integer-valued arithmetic expressions in the context of a
> symbol table that defines integer values for a set of names.  The
> "right" thing is probably an expression parser/evaluator using ast,
> but it looked like that would take more code that the rest of the
> assembler combined, and I've got other higher-priority tasks to get
> back to.

Will ast.literal_eval do what you want?

-- 
Terry Jan Reedy

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

#36106

On Fri, 04 Jan 2013 07:24:04 -0500, Terry Reedy wrote:

> On 1/3/2013 6:25 PM, Grant Edwards wrote:
>>
>> I've written a small assembler in Python 2.[67], and it needs to
>> evaluate integer-valued arithmetic expressions in the context of a
>> symbol table that defines integer values for a set of names.  The
>> "right" thing is probably an expression parser/evaluator using ast, but
>> it looked like that would take more code that the rest of the assembler
>> combined, and I've got other higher-priority tasks to get back to.
> 
> Will ast.literal_eval do what you want?

No. Grant needs to support variables, not just literal constants, hence 
the symbol table.



-- 
Steven

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

#36114

On 2013-01-04, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Fri, 04 Jan 2013 07:24:04 -0500, Terry Reedy wrote:
>
>> On 1/3/2013 6:25 PM, Grant Edwards wrote:
>>>
>>> I've written a small assembler in Python 2.[67], and it needs to
>>> evaluate integer-valued arithmetic expressions in the context of a
>>> symbol table that defines integer values for a set of names.  The
>>> "right" thing is probably an expression parser/evaluator using ast, but
>>> it looked like that would take more code that the rest of the assembler
>>> combined, and I've got other higher-priority tasks to get back to.
>> 
>> Will ast.literal_eval do what you want?
>
> No. Grant needs to support variables, not just literal constants, hence 
> the symbol table.

Right.  ast.literal_eval() doesn't even support arithmetic expressions
involving only literal constats such as "3+1" (that's the bare minimum
requirement).  It would also be very highly desirable to allow
expressions involving symblic constants such as "PC+1".

Google has found me exapmles of ast-based code that does pretty much
what I want, but I haven't tried it yet because of that solution's 
size and complexity.

-- 
Grant Edwards               grant.b.edwards        Yow! I brought my BOWLING
                                  at               BALL -- and some DRUGS!!
                              gmail.com            

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

#36127

On Fri, 04 Jan 2013 13:33:41 +0000, Steven D'Aprano wrote:

> On Fri, 04 Jan 2013 07:24:04 -0500, Terry Reedy wrote:
> 
>> On 1/3/2013 6:25 PM, Grant Edwards wrote:
>>>
>>> I've written a small assembler in Python 2.[67], and it needs to
>>> evaluate integer-valued arithmetic expressions in the context of a
>>> symbol table that defines integer values for a set of names.  The
>>> "right" thing is probably an expression parser/evaluator using ast,
>>> but it looked like that would take more code that the rest of the
>>> assembler combined, and I've got other higher-priority tasks to get
>>> back to.
>> 
>> Will ast.literal_eval do what you want?
> 
> No. Grant needs to support variables, not just literal constants, hence
> the symbol table.

as a thought why not processes the input string by exploding the literal 
constants into their numerical values as stage 1
this should result in a string that only contains numbers & mathematical 
symbols then reject any resultant string that contains any alpha 
characters.

I have to agree that it is still a risky process.

 



-- 
Loneliness is a terrible price to pay for independence.

[toc] | [prev] | [standalone]

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

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

csiph-web