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

Replies are listed 'Best First'.
Re^3: Why do poisoned null attacks still work ? by JavaFan (Canon) on Jul 22, 2009 at 16:16 UTC
I agree that scripts should* use taint, but what if they don't ?* Then they don't, and take a risk. I don't find, in general, the argument "what if people ignore the safety devices we give them?" very valid. http://www.securityfocus.com/archive/1/317234, which to my reading looks like a dodgy old CGI script that would cease to be exploitable if the Perl interpreter had poisoned null countermeasures. 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. Seems like a good thing to me, maybe I will take a stab at writing a patch. You might consider using an embedded NUL for system calls a warning - people can than use FATAL to upgrade the warning to an exception.	[reply]
Re^4: Why do poisoned null attacks still work ? by pubnoop (Acolyte) on Jul 23, 2009 at 07:32 UTC
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 ?	[reply]
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]