3 ms·

> You didn't address my concerns at all. You asked a question, I provided the answer and example code to the actual question that you asked. > My question was

by lutusp 12y ago

> You didn't address my concerns at all. 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.

morgante 12y ago
> 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.
- lutusp 12y ago
  > 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: https://blog.cloudflare.com/inside-shellshock/ https://blog.cloudflare.com/inside-shellshock/
  - xorcist 12y ago
    > many existing PHP pages, as just one example. 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.

by lutusp 12y ago

morgante 12y ago

> 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.

lutusp 12y ago
> 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: https://blog.cloudflare.com/inside-shellshock/ https://blog.cloudflare.com/inside-shellshock/
- xorcist 12y ago
  > many existing PHP pages, as just one example. 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.