Re^4: Why do poisoned null attacks still work ?

From the description of the code, it seems that 1) the code doesn't use taint - the substitution on the cookie failed, so the cookie would still have been tainted. 2) the cookie is interpolated into a string, then evalled. I'm pretty sure that leaves many other possibilities to execute arbitrary code.

In this specific case, there is a test that a filename including the cookie string exists before the eval. Poisoned null on the stat call allows that test to be fooled. Without the poisoned null trick, only existing directory names can be shoved into the string to be evaled, making the exploit harder and maybe impossible in some cases.

I bet there are more scripts out there that are currently exploitable due to poisoned null. Wouldn't it be nice (from the web hoster's point of view) for those vulnerabilities to vanish the next time the hoster upgrades Perl ?

Comment on Re^4: Why do poisoned null attacks still work ?

Replies are listed 'Best First'.
Re^5: Why do poisoned null attacks still work ? by JavaFan (Canon) on Jul 23, 2009 at 08:59 UTC
In this specific case, there is a test that a filename including the cookie string exists before the eval. Poisoned null on the stat call allows that test to be fooled. Without the poisoned null trick, only existing directory names can be shoved into the string to be evaled, making the exploit harder and maybe impossible in some cases. Without seeing the code, it's impossible to be sure. But still, the cookie wasn't detainted, and tainting wasn't turned on (otherwise, taint checking would have tripped this). I bet there are more scripts out there that are currently exploitable due to poisoned null. Wouldn't it be nice (from the web hoster's point of view) for those vulnerabilities to vanish the next time the hoster upgrades Perl ? Oh, very nice. I guess. Still, I can't really get very excited about a script, running in a hostile environment, doing string evals without taint checking, having one angle of attack closed several years down the line, by the time the hoster upgrades to 5.12. Either the script has been exploited by then, or hackers don't find it worthwhile in the first place. Wouldn't it be much better if said script got '-T' added?	[reply]

Replies are listed 'Best First'.

Re^5: Why do poisoned null attacks still work ?
by JavaFan (Canon) on Jul 23, 2009 at 08:59 UTC

In this specific case, there is a test that a filename including the cookie string exists before the eval. Poisoned null on the stat call allows that test to be fooled. Without the poisoned null trick, only existing directory names can be shoved into the string to be evaled, making the exploit harder and maybe impossible in some cases.

I bet there are more scripts out there that are currently exploitable due to poisoned null. Wouldn't it be nice (from the web hoster's point of view) for those vulnerabilities to vanish the next time the hoster upgrades Perl ?

Wouldn't it be much better if said script got '-T' added?

[reply]