Re: [sympy] eval() evil - sympify() safe?

156 views
Skip to first unread message

Aaron Meurer

unread,
May 23, 2013, 8:34:37 PM5/23/13
to sy...@googlegroups.com
sympify is *NOT* safe. It calls eval. The same tricks that you can
use to do nasty things with eval can be used from sympify. Who is
hyping it as safe?

I don't think it can be made safe either (if anyone has any ideas,
feel free to discuss them, though). The only way to protect against
arbitrary user input is to properly sandbox your app.

Aaron Meurer

On Thu, May 23, 2013 at 10:32 AM, Ja Genau <krazy...@googlemail.com> wrote:
> Hi there,
>
> sympify() is hyped as the safe alternative to evil eval().
>
> Is it really that safe that there is no way to pass a string to
> sympy.sympify(<string>).evalf() to harm the system?
>
> --
> You received this message because you are subscribed to the Google Groups
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sympy+un...@googlegroups.com.
> To post to this group, send email to sy...@googlegroups.com.
> Visit this group at http://groups.google.com/group/sympy?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Joachim Durchholz

unread,
May 24, 2013, 4:34:03 AM5/24/13
to sy...@googlegroups.com
Am 24.05.2013 02:34, schrieb Aaron Meurer:
> I don't think it can be made safe either (if anyone has any ideas,
> feel free to discuss them, though).

It's possible if you do it the way that many JSON libraries have
defanged their input: Replacing any eval call with a parser+evaluator,
and making the evaluator call only known-to-be-safe functions.

Determining a set of safe functions would be easier than for, say, a
Javascript engine, because we could restrict it to side-effect-free
functions.
We'd have to forbid calls to unknown-to-us third-party code, so that
would be a compatibility-breaking change. The workaround for the user
would be to rewrite his code to evaluate the third-party call, and stuff
the result into a Sympy or Python variable before using sympify. This
wouldn't work for those who use some code to generate Python code and
stuff that into sympify - such an approach would be rather insane from
my perspective, but non-CS engineers do insane stuff from a CS
engineer's perspective all day and get away with it, so I don't know
whether such a thing was done or not.

tl;dr: It could be done but would require a lot of work, and it might
break some rare code.
If sandboxing the Python interpreter is easy to do, it's not worth even
considering that.

Regards,
Jo

Ja Genau

unread,
May 24, 2013, 5:40:35 AM5/24/13
to sy...@googlegroups.com


Am Freitag, 24. Mai 2013 02:34:37 UTC+2 schrieb Aaron Meurer:
sympify is *NOT* safe. It calls eval.  The same tricks that you can
use to do nasty things with eval can be used from sympify.  Who is
hyping it as safe?

Just google "sympify safe eval site:stackoverflow.com". I would guess this came up
because the root source file of sympify does not contain a call to eval and following
down function calls is tedious...

Ronan Lamy

unread,
May 24, 2013, 6:50:49 AM5/24/13
to sy...@googlegroups.com
2013/5/24 Joachim Durchholz <j...@durchholz.org>
Am 24.05.2013 02:34, schrieb Aaron Meurer:

I don't think it can be made safe either (if anyone has any ideas,
feel free to discuss them, though).

tl;dr: It could be done but would require a lot of work, and it might break some rare code.
If sandboxing the Python interpreter is easy to do, it's not worth even considering that.
 
It is *not* easy. Actually, it's probably best to assume that it's not possible at all.

Having a safer way of parsing user input inside sympy would be rather useful.

Aaron Meurer

unread,
May 24, 2013, 11:04:53 AM5/24/13
to sy...@googlegroups.com
On Fri, May 24, 2013 at 4:50 AM, Ronan Lamy <ronan...@gmail.com> wrote:
> 2013/5/24 Joachim Durchholz <j...@durchholz.org>
>>
>> Am 24.05.2013 02:34, schrieb Aaron Meurer:
>>
>>> I don't think it can be made safe either (if anyone has any ideas,
>>> feel free to discuss them, though).
>>
>>
>> tl;dr: It could be done but would require a lot of work, and it might
>> break some rare code.
>> If sandboxing the Python interpreter is easy to do, it's not worth even
>> considering that.
>
>
> It is *not* easy. Actually, it's probably best to assume that it's not
> possible at all.

I guess you could put everything in a VM. I agree it's nontrivial, and
it's not my area of expertise.

>
> Having a safer way of parsing user input inside sympy would be rather
> useful.

This is tricky, because it's easy to miss some roundabout way of
accessing things. Using just function calls, I can access the sys
module from just Symbol('x') (technically it uses attributes and
getitem, but those can both be done using getattr). I *think* forcing
all names to parse to a SymPy class or a Symbol/Function and disabling
attribute access should be OK, but there may be ways to do things even
with that.

Aaron Meurer
Reply all
Reply to author
Forward
0 new messages