# Who should be most worried about "Shellshock," the Unix/Linux vulnerability?

**URL:** <https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781>\
**Category:** Factual Questions\
**Created:** [September 28, 2014, 3:56pm UTC](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781 "2014-09-28T15:56:19Z")\
**Posts on this page:** 5\
**Page:** 2

<div class="post-metadata">

**Author:** ![Chronos](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/chronos/32/134_2.png) [@Chronos](https://boards.straightdope.com/u/Chronos)\
**Post date:** [September 30, 2014, 3:43pm UTC](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781/21 "2014-09-30T15:43:43Z")

</div>

> [@](#):
>
> Quoth **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. There are scant few people in the open source community who are willing to take on the less than glorious job of QA. Everyone wants to be a hero and write new stuff.

OK. Are there more people reviewing the code in the closed-source community?

---

<div class="post-metadata">

**Author:** ![gotpasswords](https://avatars.discourse-cdn.com/v4/letter/g/c57346/32.png) [@gotpasswords](https://boards.straightdope.com/u/gotpasswords)\
**Post date:** [September 30, 2014, 8:52pm UTC](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781/22 "2014-09-30T20:52:55Z")

</div>

[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

---

<div class="post-metadata">

**Author:** ![Francis\_Vaughan](https://sea3.discourse-cdn.com/straightdope/user_avatar/boards.straightdope.com/francis_vaughan/32/3093_2.png) [@Francis\_Vaughan](https://boards.straightdope.com/u/Francis_Vaughan)\
**Post date:** [October 1, 2014, 12:51am UTC](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781/23 "2014-10-01T00:51:09Z")

</div>

> [@Chronos](#):
>
> OK. Are there more people reviewing the code in the closed-source community?

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.

---

<div class="post-metadata">

**Author:** ![si\_blakely](https://avatars.discourse-cdn.com/v4/letter/s/d9b06d/32.png) [@si\_blakely](https://boards.straightdope.com/u/si_blakely)\
**Post date:** [October 1, 2014, 9:48am UTC](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781/24 "2014-10-01T09:48:38Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![zwede](https://avatars.discourse-cdn.com/v4/letter/z/ac91a4/32.png) [@zwede](https://boards.straightdope.com/u/zwede)\
**Post date:** [October 1, 2014, 11:35am UTC](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781/25 "2014-10-01T11:35:15Z")

</div>

> [@Francis\_Vaughan](#):
>
> 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.

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.

[Previous page](https://boards.straightdope.com/t/who-should-be-most-worried-about-shellshock-the-unix-linux-vulnerability/699781.md?page=1)