> You asked a question, I provided the answer and example code to the actual question that you asked.
No, you must emphatically did not.
This is the question I asked:
> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Put more clearly, I was asking for an example of a modern, well-developed website which would be vulnerable to Shellshock. (I don't think anyone would characterize CGI scripts as modern.) Your question didn't get anywhere near providing that.
I don't need a condescending explanation of why Shellshock is bad if you open a shell. I need an explanation (preferably with an example of actual code) of why somebody is actually shelling out in a modern web app.
Put another way, Shellshock could literally cause a computer to explode anytime a shell is opened from the app. This doesn't change my opinion that there's no reason modern websites are opening shells—and nothing you've said provides evidence of that.
> This doesn't change my opinion that there's no reason modern websites are opening shells—and nothing you've said provides evidence of that.
What? Evidence of your opinion? I live in reality, one not informed by opinions, and there are plenty of sites that were designed to be secure, but that didn't anticipate something like Shellshock -- many existing PHP pages, as just one example.
Setting environment variables is very common, and safe if the shell is safe, because a sound shell won't do anything with an environment variable setting action beyond setting an environment variable.
Consider a prudent design that sanitizes the entry to limit itself to an alphanumeric variable name and a value provided by the user, as in my example. The left-hand side of the assignment is not an issue because the program checks its content for malicious intent. The right-hand side is safe if Bash is safe. If Bash is safe and if rudimentary precautions are taken, any variable-assigned text string is benign.
Not so for Shellshock, which is why it caused such consternation among Website operators.
Here's an online reference that makes the same points I do, and even uses the same example of reading /etc/passwd:
Not really. Deploying PHP with CGI is very uncommon, as we've seen from the fallout from CVE-2012-1823 which was a much worse bug. Anything vulnerable to that has the potential of being vulnerable again, but that wasn't what you would think of as web applications: some embedded web interfaces, some really bad control panels, that sort of thing.
No, you must emphatically did not.
This is the question I asked:
> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Put more clearly, I was asking for an example of a modern, well-developed website which would be vulnerable to Shellshock. (I don't think anyone would characterize CGI scripts as modern.) Your question didn't get anywhere near providing that.
I don't need a condescending explanation of why Shellshock is bad if you open a shell. I need an explanation (preferably with an example of actual code) of why somebody is actually shelling out in a modern web app.
Put another way, Shellshock could literally cause a computer to explode anytime a shell is opened from the app. This doesn't change my opinion that there's no reason modern websites are opening shells—and nothing you've said provides evidence of that.