Security of Python's eval() on untrusted strings?
Question:
If I am evaluating a Python string using eval(), and have a class like:
class Foo(object):
a = 3
def bar(self, x): return x + a
What are the security risks if I do not trust the string? In particular:
- Is
eval(string, {"f": Foo()}, {}) unsafe? That is, can you reach os or sys or something unsafe from a Foo instance?
- Is
eval(string, {}, {}) unsafe? That is, can I reach os or sys entirely from builtins like len and list?
- Is there a way to make builtins not present at all in the eval context?
There are some unsafe strings like “[0] * 100000000” I don’t care about, because at worst they slow/stop the program. I am primarily concerned about protecting user data external to the program.
Obviously, eval(string) without custom dictionaries is unsafe in most cases.
Answers:
eval() will allow malicious data to compromise your entire system, kill your cat, eat your dog and make love to your wife.
There was recently a thread about how to do this kind of thing safely on the python-dev list, and the conclusions were:
- It’s really hard to do this properly.
- It requires patches to the python interpreter to block many classes of attacks.
- Don’t do it unless you really want to.
Start here to read about the challenge: http://tav.espians.com/a-challenge-to-break-python-security.html
What situation do you want to use eval() in? Are you wanting a user to be able to execute arbitrary expressions? Or are you wanting to transfer data in some way? Perhaps it’s possible to lock down the input in some way.
You are probably better off turning the question around:
- What sort of expressions are you wanting to eval?
- Can you insure that only strings matching some narrowly defined syntax are eval()d?
- Then consider if that is safe.
For example, if you are wanting to let the user enter an algebraic expression for evaluation, consider limiting them to one letter variable names, numbers, and a specific set of operators and functions. Don’t eval() strings containing anything else.
Note that even if you pass empty dictionaries to eval(), it’s still possible to segfault (C)Python with some syntax tricks. For example, try this on your interpreter: eval("()"*8**5)
You can get to os using builtin functions: __import__('os').
For python 2.6+, the ast module may help; in particular ast.literal_eval, although it depends on exactly what you want to eval.
There is a very good article on the un-safety of eval() in Mark Pilgrim’s Dive into Python tutorial.
Quoted from this article:
In the end, it is possible to safely
evaluate untrusted Python expressions,
for some definition of “safe” that
turns out not to be terribly useful in
real life. It’s fine if you’re just
playing around, and it’s fine if you
only ever pass it trusted input. But
anything else is just asking for
trouble.
You cannot secure eval with a blacklist approach like this. See Eval really is dangerous for examples of input that will segfault the CPython interpreter, give access to any class you like, and so on.
If I am evaluating a Python string using eval(), and have a class like:
class Foo(object):
a = 3
def bar(self, x): return x + a
What are the security risks if I do not trust the string? In particular:
- Is
eval(string, {"f": Foo()}, {})unsafe? That is, can you reach os or sys or something unsafe from a Foo instance? - Is
eval(string, {}, {})unsafe? That is, can I reach os or sys entirely from builtins like len and list? - Is there a way to make builtins not present at all in the eval context?
There are some unsafe strings like “[0] * 100000000” I don’t care about, because at worst they slow/stop the program. I am primarily concerned about protecting user data external to the program.
Obviously, eval(string) without custom dictionaries is unsafe in most cases.
eval() will allow malicious data to compromise your entire system, kill your cat, eat your dog and make love to your wife.
There was recently a thread about how to do this kind of thing safely on the python-dev list, and the conclusions were:
- It’s really hard to do this properly.
- It requires patches to the python interpreter to block many classes of attacks.
- Don’t do it unless you really want to.
Start here to read about the challenge: http://tav.espians.com/a-challenge-to-break-python-security.html
What situation do you want to use eval() in? Are you wanting a user to be able to execute arbitrary expressions? Or are you wanting to transfer data in some way? Perhaps it’s possible to lock down the input in some way.
You are probably better off turning the question around:
- What sort of expressions are you wanting to eval?
- Can you insure that only strings matching some narrowly defined syntax are eval()d?
- Then consider if that is safe.
For example, if you are wanting to let the user enter an algebraic expression for evaluation, consider limiting them to one letter variable names, numbers, and a specific set of operators and functions. Don’t eval() strings containing anything else.
Note that even if you pass empty dictionaries to eval(), it’s still possible to segfault (C)Python with some syntax tricks. For example, try this on your interpreter: eval("()"*8**5)
You can get to os using builtin functions: __import__('os').
For python 2.6+, the ast module may help; in particular ast.literal_eval, although it depends on exactly what you want to eval.
There is a very good article on the un-safety of eval() in Mark Pilgrim’s Dive into Python tutorial.
Quoted from this article:
In the end, it is possible to safely
evaluate untrusted Python expressions,
for some definition of “safe” that
turns out not to be terribly useful in
real life. It’s fine if you’re just
playing around, and it’s fine if you
only ever pass it trusted input. But
anything else is just asking for
trouble.
You cannot secure eval with a blacklist approach like this. See Eval really is dangerous for examples of input that will segfault the CPython interpreter, give access to any class you like, and so on.