It's Bash's turn to have a security hole

[bloomo]

That is a fail. It does not indicate that you are vulnerable. In order to actually be vulnerable, you need to be able to have something that would call it in a manner that would be exploitable.

We could just as easily (and just as incorrectly) argue that /bin/sh is vulnerable if you can type "/bin/sh -c id" and the system responds "uid=0(root)". Because if you do that from a root shell, well, yeah, then it is "vulnerable" in some perverse sense.

So far, the WebGUI console is the only thing that's been identified as running bash, and that's already running as root, so it is already at escalated privilege and not vulnerable.

That's why newbies like me should not look at the internet :) Thanks for clearing that up.

 

[mattlach]

That is a fail. It does not indicate that you are vulnerable. In order to actually be vulnerable, you need to be able to have something that would call it in a manner that would be exploitable.

We could just as easily (and just as incorrectly) argue that /bin/sh is vulnerable if you can type "/bin/sh -c id" and the system responds "uid=0(root)". Because if you do that from a root shell, well, yeah, then it is "vulnerable" in some perverse sense.

So far, the WebGUI console is the only thing that's been identified as running bash, and that's already running as root, so it is already at escalated privilege and not vulnerable.

Would you mind expanding on this?

How does running as root make it less vulnerable?

I would have imagined that it would be even more concerning if something running at root were exposed like this? Or does bash treat environment variables differently if executing them as root, as opposed to executing them as an individual user?

Either way, webgui really should not be exposed to the outside network. That would be a silly thing to do.

 

[anodos]

Would you mind expanding on this?

How does running as root make it less vulnerable?

I would have imagined that it would be even more concerning if something running at root were exposed like this? Or does bash treat environment variables differently if executing them as root, as opposed to executing them as an individual user?

Either way, webgui really should not be exposed to the outside network. That would be a silly thing to do.

I think the point is that if you have compromised the webgui, you already have root. Game over. There's no need to escalate privileges. What you are talking about is like that scene in Jumanji where the boy grabs an ax to break down the door to the shed where they keep the ax.

 

[mattlach]

I think the point is that if you have compromised the webgui, you already have root. Game over. There's no need to escalate privileges. What you are talking about is like that scene in Jumanji where the boy grabs an ax to break down the door to the shed where they keep the ax.

Ahh, fair enough. That makes sense. Either way, bash bug or not, it is not a good idea to expose the webgui to the outside world

 

[mattlach]

Actually thinking more about it, I'm still confused.

I didn't think privilege escalation was necessarily a part of this problem, but maybe I misunderstood how it works.

I was under the impression that because of this environment variable issue, bash could be made to execute arbitrary commands/code, and that this was a huge problem, because many web configurations (especially with Apache) execute bash scripts directly as part of the http address...

So if I understood it properly, a would be attacker could alter the http address (including all those "&" and "?" statements, and doing so get bash ton execute arbitrary commands and code.

It would seem to me, that if your apache is running and executing these as root, it would be worse, not better.

It is completely possible (and likely!) that my understanding on this is flawed though. I'm - from an understanding perspective - a mid-level *nix practitioner and user, by no means a security expert or coder.

 

[anodos]

Actually thinking more about it, I'm still confused.

I didn't think privilege escalation was necessarily a part of this problem, but maybe I misunderstood how it works.

I was under the impression that because of this environment variable issue, bash could be made to execute arbitrary commands/code, and that this was a huge problem, because many web configurations (especially with Apache) execute bash scripts directly as part of the http address...

So if I understood it properly, a would be attacker could alter the http address (including all those "&" and "?" statements, and doing so get bash ton execute arbitrary commands and code.

It would seem to me, that if your apache is running and executing these as root, it would be worse, not better.

It is completely possible (and likely!) that my understanding on this is flawed though. I'm - from an understanding perspective - a mid-level *nix practitioner and user, by no means a security expert or coder.

The webserver is nginx. I'm pretty sure you would have to be authenticated to run a command through a malformed URL.

 

[cyberjock]

Ok, so just got some info from a dev. If any of this is incorrect you can blame me later.

1. If you are truly concerned about the vulnerability, the fix is simple- delete the bash binary at /usr/local/bin/bash.
2. FreeNAS only uses bash in the WebGUI, which you must already authenticate for by logging into the WebGUI. So you've already got root access at that point, so running "arbitrary" code from a vulnerable bash doesn't matter because you can already run arbitrary code from the shell in the WebGUI or by SSHing into the box and authenticating as root. Do note that if someone can get WebGUI access then can do things like change the root password, turn on SSH and allow logins with passwords, set SSH keys for root authentication, etc so your security model is already broken if someone is able to authenticate as root for purposes of gaining access to the WebGUI.
3. FreeNAS doesn't use bash in any form outside of the WebGUI shell. Obviously if you've taken some initiative to create scripts that run bash, that's on you to ensure you aren't doing anything that might give your script root access unknowingly.
4. There's some discussion going on still on whether the patch *actually* solves the vulnerability to 100%.
5. The "patch" in it's present form is implemented already and will be in the next FreeNAS release. Now whether that will be a 9.2.1.x or 9.3 is up in the air, and there is no ETA on when either will be released. The risk of having problems with the vulnerable bash are virtually non-existent because of how FreeNAS is designed, so an immediate FreeNAS rollout isn't deemed as immediately necessary. But it is acknowledged that people are concerned about the bug and want it fixed. If you're that worried see #1.

So I think that at this point, if you are concerned:

1. You should realize that for this to be exploited you have to have broken other faux pas on FreeNAS anyway.
2. If you want to be extra super paranoid then delete the bash binary. Paranoia solved!

 

[jgreco]

That's how I figured it'd be. It is effectively not an issue unless you go out of your way to make it one.

 

[mattlach]

Thank you for explaining that cyberjock. The reasoning makes perfect sense to me now.

 

[Robert Smith]

Ha ha, funny; this thread triggered my intrusion protection system.

 

[mattlach]

5. The "patch" in it's present form is implemented already and will be in the next FreeNAS release. Now whether that will be a 9.2.1.x or 9.3 is up in the air, and there is no ETA on when either will be released.

Something I ahve found interesting is that FreeBSD releases must be more difficult to work with than in the Linux world.

All the BSD based releases that I am familiar with (well, I only use pfSense and FreeNAS) are always a few releases behind current stable FreeBSD, whereas in the Linux world derivative releases are usually no more than a couple of months behind (like Mint is to Ubuntu, etc.)

 

[mattlach]

5. The "patch" in it's present form is implemented already and will be in the next FreeNAS release. Now whether that will be a 9.2.1.x or 9.3 is up in the air, and there is no ETA on when either will be released.

Something I ahve found interesting is that FreeBSD releases must be more difficult to work with than in the Linux world.

All the BSD based releases that I am familiar with (well, I only use pfSense and FreeNAS) are always a few releases behind current stable FreeBSD, whereas in the Linux world derivative releases are usually no more than a couple of months behind (like Mint is to Ubuntu, etc.)

 

[jager]

Ok, so just got some info from a dev. If any of this is incorrect you can blame me later.

1. If you are truly concerned about the vulnerability, the fix is simple- delete the bash binary at /usr/local/bin/bash.
2. FreeNAS only uses bash in the WebGUI, which you must already authenticate for by logging into the WebGUI. So you've already got root access at that point, so running "arbitrary" code from a vulnerable bash doesn't matter because you can already run arbitrary code from the shell in the WebGUI or by SSHing into the box and authenticating as root. Do note that if someone can get WebGUI access then can do things like change the root password, turn on SSH and allow logins with passwords, set SSH keys for root authentication, etc so your security model is already broken if someone is able to authenticate as root for purposes of gaining access to the WebGUI.
3. FreeNAS doesn't use bash in any form outside of the WebGUI shell. Obviously if you've taken some initiative to create scripts that run bash, that's on you to ensure you aren't doing anything that might give your script root access unknowingly.
4. There's some discussion going on still on whether the patch *actually* solves the vulnerability to 100%.
5. The "patch" in it's present form is implemented already and will be in the next FreeNAS release. Now whether that will be a 9.2.1.x or 9.3 is up in the air, and there is no ETA on when either will be released. The risk of having problems with the vulnerable bash are virtually non-existent because of how FreeNAS is designed, so an immediate FreeNAS rollout isn't deemed as immediately necessary. But it is acknowledged that people are concerned about the bug and want it fixed. If you're that worried see #1.

So I think that at this point, if you are concerned:

1. You should realize that for this to be exploited you have to have broken other faux pas on FreeNAS anyway.
2. If you want to be extra super paranoid then delete the bash binary. Paranoia solved!

How do I delete the bash binary on the read only filesystem that holds the base image? The irc says 'never mess with the base system', basically. I tried to mount -o rw / as root but it seems not to work. Is this actually possible? (edit) I would actually like to, if editing the base system is possible, edit /usr/local/www/freenasUI/tools/webshell.py to point to csh. But I can't, for the same reason I can't erase bash.

 

[cyberjock]

Like this:

# mount -uw /
# rm /usr/local/bin/bash
# mount -ur /

 

[jager]

Like this:

# mount -uw /
# rm /usr/local/bin/bash
# mount -ur /

Hey thanks that worked just fine. You're the man!

 

[xcom]

Like this:

# mount -uw /
# rm /usr/local/bin/bash
# mount -ur /

WoW. This is shocking.

 

[jgreco]

Something I ahve found interesting is that FreeBSD releases must be more difficult to work with than in the Linux world.

All the BSD based releases that I am familiar with (well, I only use pfSense and FreeNAS) are always a few releases behind current stable FreeBSD, whereas in the Linux world derivative releases are usually no more than a couple of months behind (like Mint is to Ubuntu, etc.)

Well, that's kind of a weird thing to say. pfSense and FreeNAS are not "FreeBSD releases". They are products built on top of FreeBSD, designed to make FreeBSD easier to use. Since users expect that the management layer offered by these appliances will work correctly, and since that's all very dependent on changes that may have happened between releases, including things like new features, changed drivers, etc., there's a certain amount of qualification and validation that goes on to make sure it works. That takes time to write code to adapt to the new features, more time to test those changes, etc.

You may note that FreeNAS tracks FreeBSD 9, not FreeBSD 10 or FreeBSD 11, because that is where the most significant active development is going on, and therefore also where the greatest risk lies. For an appliance, there's no need to have every latest and newest feature if it might mean compromising the stability of the platform. Instead, a more conservative approach means that a new disruptive (and irrelevant) feature in -CURRENT isn't going to be an issue to your storage appliance's stability.

Also, in the IT world, it is quite common for a company like Cisco to release a new version of software and for companies not to deploy it on day one, because it is invariably better to let someone else discover if there are problems with the new release. Because sometimes there are. So when FreeBSD 9.4 comes out, it might be a little while before a FreeNAS release comes out based on that.

Further, iX has based FreeNAS off of TrueOS, which is based off FreeBSD. This puts the brakes on change propagation even more, and allows them to pick and choose certain features. It is a lot of work to go that route, but it pays off in that we've had a very stable FreeBSD variant acting as the basis of FreeNAS.

It's a more professional model than what might go on elsewhere. It isn't perfect but it has been cranking out a great stable server OS for twenty years.

 

[anodos]

Something I ahve found interesting is that FreeBSD releases must be more difficult to work with than in the Linux world.

All the BSD based releases that I am familiar with (well, I only use pfSense and FreeNAS) are always a few releases behind current stable FreeBSD, whereas in the Linux world derivative releases are usually no more than a couple of months behind (like Mint is to Ubuntu, etc.)

That's because you're looking at the hobbiest Linux distros. At work I wouldn't consider using anything other than rhel or centos. People still are on rhel 5 and most products are based on rhel 6. Hardly anyone uses rhel 7.

 

[jgreco]

Which simultaneously matches up with my "not-bleeding-edge" assessment, while also showing off one of the greatest weaknesses of Linux... the dozen different "distros".

 

[mattlach]

Well, that's kind of a weird thing to say. pfSense and FreeNAS are not "FreeBSD releases". They are products built on top of FreeBSD, designed to make FreeBSD easier to use. Since users expect that the management layer offered by these appliances will work correctly, and since that's all very dependent on changes that may have happened between releases, including things like new features, changed drivers, etc., there's a certain amount of qualification and validation that goes on to make sure it works. That takes time to write code to adapt to the new features, more time to test those changes, etc.

You may note that FreeNAS tracks FreeBSD 9, not FreeBSD 10 or FreeBSD 11, because that is where the most significant active development is going on, and therefore also where the greatest risk lies. For an appliance, there's no need to have every latest and newest feature if it might mean compromising the stability of the platform. Instead, a more conservative approach means that a new disruptive (and irrelevant) feature in -CURRENT isn't going to be an issue to your storage appliance's stability.

Also, in the IT world, it is quite common for a company like Cisco to release a new version of software and for companies not to deploy it on day one, because it is invariably better to let someone else discover if there are problems with the new release. Because sometimes there are. So when FreeBSD 9.4 comes out, it might be a little while before a FreeNAS release comes out based on that.

Further, iX has based FreeNAS off of TrueOS, which is based off FreeBSD. This puts the brakes on change propagation even more, and allows them to pick and choose certain features. It is a lot of work to go that route, but it pays off in that we've had a very stable FreeBSD variant acting as the basis of FreeNAS.

It's a more professional model than what might go on elsewhere. It isn't perfect but it has been cranking out a great stable server OS for twenty years.

Thank you for the explanation. Been running servers for 15 years, but as a hobbyist, not as an IT professional, so I am learning the extra precautions people in that field take.

I definitely understand the stability over bleeding edge argument, but I was always under the impression that current stable releases were sufficient for these goals, and only unstable releases needed to be avoided.

Honestly, I haven't had any stability issues in any stable FOSS server OS release since the early days of Gentoo Linux, which was the very opposite of what we are going for, bleeding edge, but something would break every freaking time I ran an update.

That's because you're looking at the hobbiest Linux distros. At work I wouldn't consider using anything other than rhel or centos. People still are on rhel 5 and most products are based on rhel 6. Hardly anyone uses rhel 7.

I have settled on Ubuntu Server Edition LTS releases for all my servers. On the client side they are definitely very hobbyist, and I HATE the GUI they have settled on (which is why I run a different distribution as my desktop), but on the server side Canonical offers support, features and stability inline with RHEL and CentOS, and (well, RHEL's support is tough to beat, but they are up there) and apparently the market agrees judging by enterprise adoption rates, which show Ubuntu Server outpacing RHEL in many adoption statistics.

That being said, as far as I am concerned, there is no hoop to big to jump through to avoid having to use the RPM package manager. I hate hate hate that package manager. Hated it back in the 90's and I hate it today. So, I may be a bit biased. I would - for my own projects - avoid anything based on RPM at almost any cost.

Anyway, this is starting to get WAY off topic, so my apologies.