env x='() { :;}; echo OOPS' bash -c :
The “env” command runs a command with a given variable set. In this case, we’re setting “x” to something that looks like a function. The function is just a single “:”, which is actually a simple command which is defined as doing nothing. But then, after the semi-colon which signals the end of the function definition, there’s an echo command. That’s not supposed to be there, but there’s nothing stopping us from doing it.

via Shellshock: How does it actually work? | Fedora Magazine.

But — oops! When that new shell starts up and reads the environment, it gets to the “x” variable, and since it looks like a function, it evaluates it. The function definition is harmlessly loaded — and then our malicious payload is triggered too. So, if you run the above on a vulnerable system, you’ll get “OOPS” printed back at you. Or, an attacker could do a lot worse than just print things.

I copied and pasted the above env command and it echos back OOPS.  This web server has been (I suspect) scanned already once with the scanner placing a ping command in the User Agent HTTP field.  Apparently User Agent gets passed to a shell environmental variable which will then get executed.  The only problem is that they need some kind of script to execute which there are none on this site.  This site simply returned 404, file not found to the scanner.

This could be problematic on sites with a lot of cgi scripts.  There is some exploit that can affect a client using dhcp to obtain an IP address from a malicious server.  I’ll find an explanation of that and put that up in its own post.   This story is evolving and even has its own brand name now — shellshock.