Bash security vulnerbility

What about the DHCP client ?

Hi Ondrej,

That's some good analysis, and as for the source, an exhaustive review of the code was done by our dev teams, and there is no point when user submitted data is passed to an environment variable, or to a bash call.

well according to an article on lifehacker this shows ASTARO UTM vulnerable

loginuser@astaro:/home/login > bash --version
GNU bash, version 3.2.51(1)-release (i686-suse-linux-gnu)
Copyright (C) 2007 Free Software Foundation, Inc.
loginuser@astaro:/home/login > env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello
loginuser@astaro:/home/login >
loginuser@astaro:/home/login > version

Current software version...: 9.206035
Hardware type..............: Software Appliance
Installation image.........: 9.201-25.1

Hi Jag,

Your concern is understandable, since there's a lot of attention over this issue, and not a lot of clear explanation - but the test that life hacker and countless other sites have posted is somewhat misleading. Yes, Sophos uses an affected version of bash, which is what all our announcements have said, and you've again confirmed with this test. 

The vulnerability is only meaningful if someone can use it to run something on the UTM shell, without first logging into the UTM's shell. A web server running Apache on Linux with a vulnerable bash shell might be vulnerable if the website passes form data entered by a user, to a cgi bash script, and that script stores the data in an environment variable. Then, if a malicious user could enter something in a form field, similar to what you did in your test above - but with a more malicious payload than "echo vulnerable", then this bash behavior is a big problem. An untrusted user is able to send commands of their choice to the shell, and run them.

For the system to be vulnerable, it need to a) have a vulnerable version of bash, and b) handle user submitted data in a vulnerable way. If only the first part is present, then there is no vulnerability. 

By itself, the bash vulnerability is just a quirky behavior. If you're logged into a bash shell, as you were to run the test, it doesn't let you do anything you couldn't already do. It's only a vulnerability if some other process like a web server lets untrusted users send commands to run on the shell.

If my explanation isn't as clear to you as it is to me, you might be interested in this write-up here for some more info:
Bash

The vulnerability is only meaningful if someone can use it to run something on the UTM shell, without first logging into the UTM's shell

Again, what about the DHCP client built into Astaro ? It is my understanding that, by default, it it exploitable through a rogue DHCP (POC here).

The main issue in my opinion is that when sh redirects to bash, it's used in so many places that it is hard to get high degree of confidence in statements like "there is no place where user-generated content is passed to bash through environment".

A quick patch of all UTM systems seems really the only responsible answer here from Sophos and, so far, I must say I'm disapointed by what we got: Security is supposed to be the trade in which the company is dealing and the answer we're getting and the delay in producting a patch all points to problems following the "security in depth" concepts. Given the number of UTM devices my company has deployed (and their importance) this concerns me to the highest point.

Again, what about the DHCP client built into Astaro ? It is my understanding that, by default, it it exploitable through a rogue DHCP (POC here).

The main issue in my opinion is that when sh redirects to bash, it's used in so many places that it is hard to get high degree of confidence in statements like "there is no place where user-generated content is passed to bash through environment".

A quick patch of all UTM systems seems really the only responsible answer here from Sophos and, so far, I must say I'm disapointed by what we got: Security is supposed to be the trade in which the company is dealing and the answer we're getting and the delay in producting a patch all points to problems following the "security in depth" concepts. Given the number of UTM devices my company has deployed (and their importance) this concerns me to the highest point.

You need to get involved with a reseller who is highly plugged into sophos,  Sophos has already publicly announced that UTM may contain the vulnerable bash code but the UTM product is NOT vulnerable because it does not run anything using bash scripting.  It's time to calm down everyone.  Follow best practicies, watch for various announcements and stay calm.  

here's the sophos announcement: Sophos products and the Bash vulnerability (Shellshock)

For those who are expressing concern or disgust at this "breach" chill...UTM doesn't use bash in a way that places you in any danger.  UTM takes code form many open source projects to make itself work...that's what Linux distributions are.  Everytime there's been a REAL security issues the fix has been out within hours or days at the worst...for UTM shellshock is a NON-ISSUE so please...the sky isn't falling...UTM is still secure...and hyou can leave the worry and disappointment at the door.

thank you.

William, very well explained.

Ian[:)]

With the newest pattern, our IPS is also aware of CVE-2014-6271 (see ips-rule-list).

loginuser@firewall:/home/login > bash --version

GNU bash, version 3.2.51(1)-release (i686-suse-linux-gnu)

Still not patched... Even OSX got patched by now...

Up2Date 9.208008 package description:

Remark:
 System will be rebooted

News:
 Security Release
 Update bash package to fix potential vulnerabilities
 References: CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187
 So far we are not aware of any service on UTM actually exposing these problems to attackers, this is a precautionary update.

Bugfix:
 Fix [33059]: CVE-2014-6271 bash: specially-crafted environment variables can be used to inject shell commands [9.2]

RPM packages contained:
 bash-3.2-147.22.1.1823.g6106706.i686.rpm          
 ep-release-9.208-8.noarch.rpm