Re: Run-time taint support proposal

On Fri, December 15, 2006 5:12 pm, Ilia Alshanetsky wrote: > And here is your first exploit, let's say we say > mysql_real_escape_string() takes tainted data and makes it untainted, > what happens when this "safe" data is passed to exec(). You are going > to need to deal with different levels of taint-untainted and 1 bit is > not going to give you that flexibility. You are going to need an int/ > long, maybe even a long long. I think the presumption is that most developers smart enough to be using mysql_real_escape_string() is PROBABLY smart enough to not just blindly pass its output to exec(). Or, more likely, that most developers smart enough to use mysql_real_escape_string() will code more like: $input = $_REQUEST['input']; //tainted $input_sql = mysql_real_escape_string($input); //untainted $input_exec = escapeshellarg($input); //untainted exec("/whatever $input"); //E_ERROR Ooops, I made a typo! So "taint" will only catch, say, 99% of the naive scripters who don't filter data, and an occasional typo for the experts. Nobody is claiming it will catch this one: $input = $_REQUEST['input']; //tainted $input_sql = mysql_real_escape_string($input); //untainted $input_exec = escapeshellarg($input); //untainted exec("/whatever $input_sql"); //false negative, oh well Still sounds like it's worth considering, if the performance and maintainability penalties are not too high. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So?