I know about Shellshock and I know what it means. However, I think it's wrong to blame bash for the fact that almost everything seems to be vulnerable. Those developers were wrong by using untrusted user input in places where it didn't belong. It's the FSF's responsibility to release a fix simply because the whole world depends on their (the world's) own stupid mistakes when developing their programs.
> Those developers were wrong by using untrusted user input in places where it didn't belong.
Environment variables are text. So long as you control the name of them, and the name doesn't conflict with any other name in the system, there should be absolutely no issue with putting user input into environment variables.
Programs like bash should only be executing things that are explicitly marked as trusted code through a flag that is not contained in the value. Some distros have implemented a patch to this effect already in bash, disallowing bash from treating any environment variable whose name doesn't start with BASH_FUNC_ as anything but text. This resolves every single related vulnerability out there.
So you mean the fix is to add some magic constant that variables now have to start with?
I mean, come on, the issue is screaming at you! This is the same basic mistake of using a bunch of string concatenation to build queries for your database.
Bash is the shell I use to control my system with, it's made for convenience of the user. If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
> So you mean the fix is to add some magic constant that variables now have to start with?
That executable variables have to start with. This is a perfect fix, because attackers can never choose the names of environment variables, because we know that that's a poor idea (anyone who does it is already vulnerable to people setting LD_PRELOAD and similar things). This is simply marking certain variables as executable, while everything else is not.
The default assumption, like it or not, is that if you set some random environment variable to some random text, nothing's going to happen. It's been like that since 1993, at the latest.
> If you think in 2014 that the control path from "HTTP GET" to "200 OK" (adapt for your favorite protocol) on a modern stack should involve launching the shell with user controlled environment variables, you just can't be taken seriously.
Some things end up managing the system - DHCP, for example. It turns out that the shell is really, really good at managing *nix systems. Everyone can understand it, and everyone can figure out how to manage their system with it. The only real alternative would be perl, which nobody wants to code in, and has a greater learning barrier.
As for modern web frameworks - of course they shouldn't use CGI, although more because there's better/more performant alternatives than for security reasons. However, you find me a medium/large business which has absolutely no legacy code anywhere.
> This is the same basic mistake of using a bunch of string concatenation to build queries for your database.
Not at all. The string as a query is expected to execute. Environment variables in general are just data and not expected to be executed, even if some of them have special semantics and may indeed be executed.
