> ...if you want to audit a system against this type of attack, you'd need to examine how every packet coming into the system is handled and what data from that

> ...if you want to audit a system against this type of attack, you'd need to examine how every packet coming into the system is handled and what data from that could set envs or invoke a shell. Really? Don't you think its easier to audit the system to ensure that nobody's parsing the entire environment as if it was shell script / function definitions, threatening to execute parts of it as shell commands? Here we're talking about a system made up of several different Unix processes, passing data between them through environment variables, command line arguments, input and output. This seems to affect how people think about the problem in an unfortunate way... Pretend instead that all this happened within one process, e.g. a Ruby program - who would then be responsible for the vulnerability - person A who stored a HTTP request header in a variable or person B who decided to call eval() on that variable? To me it's quite obvious that person B is at fault.