OK. Are there more people reviewing the code in the closed-source community?
[QUOTE=Francis Vaughan]
The whole story underlines an unfortunate issue with a lot of open source code. The “many eyes” quality control ideal turns out not to be true. Nobody external has been reviewing or testing the code…
[/QUOTE]
The CVE indicates that this vulnerability is **over twenty years old. ** Many blind eyes…
There are a few command line tests to see if you’re running a vulnerable version of bash:
CVE-2014-6271:
$ env x=’() { :;}; echo vulnerable’ bash -c “echo this is a test”
A vulnerable system will return the response:
vulnerable
this is a test
A patched system will return something like:
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
this is a test
CVE-2014-7169:
$ env X=’() { (a)=>\’ bash -c “echo date”;
If vulnerable, this command will return the current date.
CVE-2014-7186:
$ bash -c ‘true <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF <<EOF’ || echo “CVE-2014-7186 vulnerable”
If vulnerable, this command will return “CVE-2014-7186 vulnerable.”
CVE-2014-7187:
$ (for x in {1…200} ; do echo “for x$x in ; do :”; done; for x in {1…200} ; do echo done ; done) | bash || echo “CVE-2014-7187 vulnerable”
If vulnerable, this command will return “CVE-2014-7187 vulnerable.”
Why are there different Common Vulnerabilities and Exposure (CVE) listings associated with this vulnerability?
The vulnerability was first assigned CVE-2014-6271. Researchers have since found additional vulnerabilties in Bash and, in some cases, the patches created to fix the issue. Here is the list as of yesterday:
CVE-2014-6271 – the original Bash vulnerability
CVE-2014-7169 – this vulnerability was able to bypass protections implemented in the first patch
CVE-2014-7186 – a Bash vulnerability through importing array variables
CVE-2014-7187 – Bash word_lineno vulnerability
CVE-2014-6277 – Bash segfault vulnerability
Some reports also include CVE-2014-6278 although this CVE is currently under review
In general yes.
Any commercial operation that sells code for a living will need to have reasonably rigorous processes in place - if they don’t it swiftly becomes a nightmare and the company goes under. Not that there isn’t a wide spectrum of what goes on. However any reasonably professional outfit will have a process for review and test. The usual rule of thumb is that the cost to create commercial code versus code that simply works is 9:1. All of that extra effort goes into documentation, process, and testing. You get professional engineers whose only job is testing. Most coding processes include code walk-throughs, where code is reviewed. I know of places where even the format of comments is reviewed.
The test suite is usually bigger than the code it tests, sometimes by a very large amount. There are test harnesses used to automatically apply all the tests - regression testing. Every bug that ever there was has test cases built, and those tests never leave the test database. (Zombie bugs are a never ending source of amusement.)
What is missing from the open source community is a community of people who are ready and willing to take on the task of proper testing and QA. Not simply being alpha and beta testers, but actually doing the hard work. It is often more work than writing the code, and you get no glory.
Today, the news is that servers running OpenVPN (a SSL-based VPN tool) may be vulnerable to an unauthenticated Shellshock attack. The server can run scripts as part of the authentication process, and the username and other details are passed to the scripts as environment variables.
This is actually pretty bad. These are internet facing systems in privileged position between the internal and external network that are capable of remote unauthenticated compromise.
The other risk is via DHCP. An attacker that can set up a DHCP server in an environment - clients that connect to that server can get DHCP options that are placed into environmental variables and used in scripts that may be run via system() or directly in bash. A good way to extend an existing compromise into a wider one.
I’m also going to say that the common theory that people probably don’t still use CGI websites of the sort that can be remotely exploited by Shellshock is somewhat wrong. Not internet meltdown bad, but there are still some internet facing systems running on old/outdated systems that are now seriously insecure. I work in the internet space, and am surprised on a daily basis by how casual some organisations are about their internet security systems.
Then why does MS Windows have such a large market share? It should have gone under a long time ago with that reasoning.
I’ve worked with closed source product development for two decades. In reality testing concentrates on making sure the function spits out the correct answer for a series of correct inputs.
Then the dev adds a few negative tests because the process says they have to. Very little thought is put into the negative tests because usually the dev is already assigned to the next task by then.
In my experience open source software is higher quality than closed source. It is also my opinion/suspicion that much existing closed source stays closed because the the companies are embarrassed about the low level of quality and afraid they’ll be mocked.