eval + taint problem

[Simon Strandgaard]

Should taint information be propagated around?
Shouldn't it also be propagated through eval?

--
Simon Strandgaard


value = 222
code = "value * 3"
code.taint
p code.tainted?
result = eval code
p result.tainted?

server> ruby a.rb
true
false




value = "evil"
p value.tainted?
code = "value.upcase!"
code.taint
p code.tainted?
eval code
p value.tainted?

server> ruby a.rb
false
true
false

 

[ts]

S> value = "evil"
S> p value.tainted?
S> code = "value.upcase!"
S> code.taint
S> p code.tainted?

$SAFE = 1

S> eval code
S> p value.tainted?


Guy Decoux

 

[Simon Strandgaard]

S> value = "evil"
S> p value.tainted?
S> code = "value.upcase!"
S> code.taint
S> p code.tainted?

$SAFE = 1

S> eval code
S> p value.tainted?

Then it raises as its suppose to..
a.rb:7:in `eval': Insecure operation - eval (SecurityError)
from a.rb:7


However in $SAFE=0, shouldn't eval propagate ?

Just wondering.

 

[ts]

S> However in $SAFE=0, shouldn't eval propagate ?

taint is useless with $SAFE = 0


Guy Decoux

 

[Simon Strandgaard]

S> However in $SAFE=0, shouldn't eval propagate ?

taint is useless with $SAFE = 0

This information is new to me.
Thanks for sharing you insight.

 

[Florian G. Pflug]

Should taint information be propagated around?
Shouldn't it also be propagated through eval?

I believe you shouldn't eval tainted code in the first place - IMHO,
tainting the result of the eval won't gain you anything, since the very
thing taint can protect you from has already happened - you evaled untrusted
code.

value = 222
code = "value * 3"
code.taint
p code.tainted?
result = eval code
p result.tainted?

server> ruby a.rb
true
false

Hm - it's hard to explain in this example, since there is no reason to use
eval here...

But take this one (assume custom_expression is submitted from a web-browser)

p custom_expression.tainted? #Gives: true
code = "(" + custom_expression + ") * 3"
p code.tainted? #Gives: true
result = eval code
p result.tainted? #Gives: false

Now assume the user submits "nil) ; system("killall apache") ; (0" as
custom_expression. When you reach the last line of my example, the exploit
is already done, and you probably don't care if the result of the exploit is
tainted or not.

Or, let's say the hacker is more experienced in ruby. He submits
"nil); class Object ; def tainted? ; false ; end ; end ; (10" as
custom_expression. Now it doesn't even matter if eval propagates the tainted
status of the code or not - after the eval, nothing will appear to be
tainted any more.

Conclusion is, that having a tainted-status propagating eval() might seem a
nice feature at first, but gives you a false sense of security at last.

greetings, Florian Pflug