[woutervdb]

What you're missing here, is that bash wasn't the software with an error. It's like you use ice cubes for building a house, observing your house is melting and then blaming the developers of ice cubes for making such horible building blocks. Ice cubes were never meant to be used to build houses with.

[clarry]

> What you're missing here, is that bash wasn't the software with an error.

Is the FSF wrong for issuing a statement which says A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway?

I think you missed the news that there's a bug in bash.

And if you're making the argument that bash should've not been used in the first place because it's an ice cube or fragile or whatever, then you are with those who make the argument that bash is bad code.

[jiggy2011]

Think of it this way.

Say that a car manufacturer builds a car for city driving and doesn't warrant or recommend it's use for off roading. However it just so happens that the car is tough enough that it makes a good offroader anyway and soon people start to buy the car for the express purpose of offroading even though the manufacturer does not recommend this use.

Some time later it becomes apparent that there is a weakness in the braking system that manifests itself after extensive offroad use but not with regular road use, and this becomes the cause of many accidents. The manufacturer then does a recall and refits the cars with an improved braking system more suitable for offroading even though they never intended (and still do not) for people to use it offroad they are just forced to accept this use case.

[woutervdb]

Great explenation. To add to your story: imagine being the car manufacturer, doing this all for free (as in beer) and still having people more or less wishing you dead for building a city car not suitable for offroad use. It simply doesn't add up and makes you feel pretty miserable, I guess.

[jameshart]

Except that, in a world where Unix systems are almost exclusively used to handle network traffic, that off-road usecase should probably be considered the default. They've been selling city cars in a country that doesn't actually have any paved roads.

[jiggy2011]

That doesn't mean that bash is suitable for handling network traffic!

[zak_mc_kracken]

Except the FSF never said anything like "Please don't use bash for CGI, it's not secure enough". If they had, then they would have to recognize that bash is not secure enough for other uses as well.

[jiggy2011]

Wouldn't that violate freedom 0?

[jeremyjh]

How does it violate your freedom to warn you of a serious danger? The fact is they didn't know bash would execute code found in arbitrary application-defined variables. And that is why GNU calls it a bug.

[jiggy2011]

Sure, it's a bug but it's not ultimately their fault that it had the impact that it did as a result of people using it for purposes they might not have had in mind.

[woutervdb]

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.

[vertex-four]

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

[revelation]

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.

[vertex-four]

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

[clarry]

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

[jameshart]

Nobody knew BASH enumerated every environment variable and - depending on its content - maybe evaluated part of it for immediate execution.

It wasn't documented and it wasn't expected. It's not part of the expectations people have for a POSIX shell.

In your metaphor, it's more like the ice cube manufacturer has been making brick-shaped ice cubes and selling them through building suppliers, and they've been widely used as a building material for many years and the ice cube maker has never said anything about the slight risk of it melting at room temperature.

What you're arguing is that bash is not and was never a solid POSIX shell.