I think that if code is bad, it should be pointed out. Some will take it as bashing. Doesn't matter. We all want to run well written, secure software. When you're getting exploited, it doesn't matter if the code was written by a saint.
Shellshock is not a critical failure in bash. It is a critical failure in thousands of people who knew a tool so useful that they decided to deploy it far beyond its scope. A tool so resilient that it it did not fall over when everyone deployed against best practices. Everyone knew in the nineties that when you execute a UNIX command with untrusted input, you clear away the environment variables first. Anyone that has untrusted input embedded within a shell script does not know what they are doing. The fact that there is a way to get bash to execute untrusted code is unsurprising. The thing that surprises me is the sheer number of developers who thought it would be otherwise in complete contrast to UNIX parables and common sense.
FTFA.
CGI was standardised in 1997 to use environment variables to pass information into the CGI program. I'm sure software existed before that that does the same - procmail, perhaps?
No software that's been touched in the past two decades should assume that the environment variable is safe. Especially not a shell, which gets used for all sorts of network-processing-related things.
People pointed out that OpenSSL had a miniscule budget and provided tons of value to the world. Once again, all you can say is mea culpa.
Either that or they should be creating alternatives and moving away from poorly written software.
The point is, when FOSS software has a bug, there's no small set of developers who are responsible. It's, in some small way, collectively all our faults. Like in the case of Bash - apparently for 20 years, we never actually checked if environment variables were executable.
All software gets compromised, all the time. Compromise rate has a lot more to do with the number of users than whether that software is open or proprietary.
I do agree that code should be able to be critiqued, but criticism is generally taken poorly by an individual when your critique is hyperbolic.
Anyone who has the ability to critique it should have spent the time it took to write an outraged blogpost and try to contribute back to the project, it would both make you feel better and look better.
You are absolutely right that contributing (even in a minor way) to OSS is difficult.
However, compared to a few "me too!" comments on your blog, and a few minutes of feeling superior to someone who actually did something, the feeling of actually contributing something real to a project (even of small value) is incomparable.
The author is (IMO, rightly) getting pissed about "technology journalists" at places like Forbes, or bankers at JP Morgan, who will smugly say stuff like, "Oh, there was a really horrible vulnerability in this software, and there's nothing we can do until those incompetent programmers get out a patch" (even if this is not explicitly said, it is often implied in these articles). They completely overlook the fact that
a) The source it right there. You think you can do a better job, please fix it and submit a patch upstream. Or post on the bugtracker.
b) The reason this is a problem is usually because of lack of sanitization of user input before passing it to bash. So that is your problem, not really bash itself. Use one of the patches out there that disable the "feature" that leads to the bug.
How many articles state stuff like "Thousands of organizations over the world use bash, yet no one has discovered this for 22 years. This means a lot of companies are not taking security seriously enough to audit the (open) source of the code they ride on."? Until we start seeing articles that address the complex social and economic aspects of the issue, I don't blame FSF supporters for being pissed at them.
If that's happening, I completely agree with you. I was mostly addressing the "bashing bash" part. Because the bashing of bash is what I've seen in the recent discussion. Not the bashing of RMS.
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.
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.
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.
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.
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.
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.
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.