3 ms·
Yup; as I mentioned before in a previous ShellShock article, it seems like if you want to audit a system against this type of attack, you'd need to examine how
by seanp2k2 12y ago
Yup; as I mentioned before in a previous ShellShock article, it seems like 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.
I have a feeling we'll be seeing different variations of this type of attack for a long time now that people are thinking about this type of vulnerability. The ways that this type of thing can be combined with other exploits are both exciting and terrifying.
- bjornsing 12y ago> ...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.