CVE-2014-6271 CVE-2014-7169 bash vulnerability

[Aciid]

Information about the Bash arbitary exploit aka "shellshock" http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

Barracuda System managed by Skynet Agent v.BOA-2.3.2 welcomes you aboard

You have new mail.
Last login: Thu Sep 25 19:24:11 2014 from xxx.xxx.xxx.xxx
server:~# env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello
server:~#

server:~# dpkg --list | grep bash
ii  bash                              4.2-2ubuntu2.1                                      GNU Bourne Again SHell

Even though users should use restricted limit shell, this exploit works with for example webserver software by sending it arbitary commands as headers Here is an example case: https://gist.github.com/anonymous/929d622f3b36b00c0be1

Fixing in BOA (ubuntu) The fixed versions are 4.3-7ubuntu1.1, 4.2-2ubuntu2.2, and 4.1-2ubuntu3.1. Users can install upgraded versions of bash before this hotfix if they are CLI capable, by installing the version that complies with your arch and release

Please push this hotfix, i'd make a PR. But I don't know about your conventions for this yet.

[omega8cc]

No, it is not BOA which is vulnerable.

Both Debian Wheezy and Squeeze have already published security update, which is due to be installed in the Debian FTP archive, so all you need to do is to run 'barracuda up-stable system' again, when it is available.

We don't plan to make new BOA release because of this, since it is just a package which has been fixed upstream and it is your responsibility to run BOA upgrades when something like this happens.

For reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760#51 https://security-tracker.debian.org/tracker/CVE-2014-7169

[Aciid]

The amount of defence in your response, of course I know that BOA is not vulnerable. I'm not trying to be hostile.

But given the case that BOA is enjoyed by hundreds of users people are using it in production. As per being loyal to your customers and community I'd say the best course of action would be to do push a hotfix. And yes I'm aware that Debian has also pushed upstream fixes to Bash, but I'm not using that so I cannot verify therefore that was both of the conditions for the vulnerability fixed.

As per you have advocated people not to upgrade packages in BOA systems, is this an exception you are advising people to make? Or does this recommendation of not upgrading, only apply to BOA managed servers by omega8cc to prevent conflicts?

[omega8cc]

What you mean by hotfix?

[omega8cc]

What you mean by hotfix?

And how you would "push" it?

[omega8cc]

As per you have advocated people not to upgrade packages in BOA systems, is this an exception you are advising people to make?

No.

Not sure if you have read my initial response, but I clearly wrote what you should do:

all you need to do is to run 'barracuda up-stable system' again, when it is available.

[omega8cc]

The amount of defence in your response

It is not about defense, it is about correcting wrong assumptions and possible misunderstandings.

[Aciid]

Well, if you have no separate release-channel for post-upgrade hotfixes, I was certainly in the know that you had. Maybe I've misread CHANGELOG all this time.

Refering to this file http://files.aegir.cc/update/boa-fix-upgrade.sh.txt , maybe something like this could be replicated for emergencies like this?

But going back in the history, you did release a fix for Heartbleed CVE-2014-0160 back in the day. How is this any different? This is far more severe.

And yes, sorry about the wrong assumptions, not trying to fearmonger here.

[Aciid]

As per you have advocated people not to upgrade packages in BOA systems, is this an exception you are advising people to make? Or does this recommendation of not upgrading, only apply to BOA managed servers by omega8cc to prevent conflicts?

This maybe outdated information, back in 2012. But yes, I have now upgraded all production servers to the new fixed versions. I assume no conflicts will rise it's only bash after all. I'd understand that PHP modules or such configurations could conflict.

[omega8cc]

Heartbleed required OpenSSL rebuild from sources. This bash thing can't be fixed by (re)building bash from sources, because all available bash versions (sources) are affected, while packages include fixed binaries compatible with respective OS versions. There is simply nothing to do beyond 'barracuda up-stable system' when updated bash package is available for your OS.=

[Aciid]

Acknowledged, thanks for the responses. I think this log now concludes for all that may stumble in here.

Keep on rocking =)