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

[Ericloewe]

http://arstechnica.com/security/201...big-security-hole-on-anything-with-nix-in-it/

Because lady luck thought to herself "Hmm, this year could use a second major security hole in software that's deployed all over the place...", it's Bash's turn.

 

[anodos]

Yay! Maybe we'll get FreeNAS 9.2.1.8 after all. Makes me just want to run OpenBSD everywhere. :)

 

[Ericloewe]

Yay! Maybe we'll get FreeNAS 9.2.1.8 after all. Makes me just want to run OpenBSD everywhere. :)

I'm currently waiting for the Xmas day announcement that GCC was actually hijacked into being a Trojan Horse that injects a variant of Stuxnet in programs over 64kB - which nobody noticed because they assumed it was one of those weird new C++ features.

Still not as crazy as OpenSSL allowing itself to be coaxed into leaking 64k chunks of random memory contents from the heap.

 

[jgreco]

I don't think it'll make you see a 9.2.1.8 unless there's something in the system that uses bash. I believe the only reason that bash is even on the system is for "user convenience."

The real problem is that a lot of the Linux variants out there needed a "/bin/sh" that was GNU licensed so some idiot looked and said "Hey, bash is a superset of sh, so we could use that". Seems like a great idea, right? Not really. This has led to an entire generation of Linux sysadmins writing "/bin/sh" scripts that are actually bash scripts (i.e. won't actually work on actual modern "/bin/sh") because they have no idea which things are universal sh-isms and which things are actually bash extensions. Or, worse, they don't care that there's a difference.

So unless you're passing environment variables into a bash shell from some untrusted source (web server, sshd, whatever) this is just one of those cases where we can chuckle at the folly of the "GNU or Bust" crowd.

 

[jgreco]

I'm currently waiting for the Xmas day announcement that GCC was actually hijacked into being a Trojan Horse that injects a variant of Stuxnet in programs over 64kB - which nobody noticed because they assumed it was one of those weird new C++ features.

Still not as crazy as OpenSSL allowing itself to be coaxed into leaking 64k chunks of random memory contents from the heap.

It's not impossible but it is rather unlikely.

For those of you who might be wondering what he's referring to,

http://programmers.stackexchange.com/questions/184874/is-ken-thompsons-compiler-hack-still-a-threat

is a fairly thorough discussion of this threat in more modern times.

 

[dlavigne]

There will be a 9.2.1.8 and it will have the bash fix (as well as the TCP SA fix from a week or so ago):
http://lists.freenas.org/pipermail/freenas-commit/2014-September/004196.html.

 

[DJ9]

This was already patched yesterday on Linux. Just a FYI. So, do your updates.

 

[anodos]

This was already patched yesterday on Linux. Just a FYI. So, do your updates.

The vulnerability is somewhat patched in linux. The patch is incomplete. See here: https://access.redhat.com/node/1200223
I believe that default installs of most BSD variants don't include bash. So the issue may or may not affect users here. The FreeNAS webgui should not be internet-facing, and it is unclear whether there is even a way to exploit this bug on FreeNAS. My remaining servers don't have bash. Overall, as far as I'm concerned it is more of a 'meh' problem.

 

[TFS_Rein]

Anybody see an issue with just removing permissions to the bash shell like a chmod 000? This should help fix the issue until it's patched in the next release yes? And am I correct in saying that it's not used by anything except if a user is configured to use bash as their main shell?

If I use the command to test for the vulnerable bash versions it returns vulnerable. The system is a production system and my boss would prefer "not exploitable" vs "highly unlikely to be exploited"

 

[anodos]

Anybody see an issue with just removing permissions to the bash shell like a chmod 000? This should help fix the issue until it's patched in the next release yes? And am I correct in saying that it's not used by anything except if a user is configured to use bash as their main shell?

If I use the command to test for the vulnerable bash versions it returns vulnerable. The system is a production system and my boss would prefer "not exploitable" vs "highly unlikely to be exploited" :)

There is a difference between 'vulnerable' and 'exploitable'. Do people have shell access to your FreeNAS? I don't think it's clear that bash is exploitable on FreeNAS in a typical use case.
I would hesitate to chmod 000 bash on a production system without doing it in a test environment first and verifying that it won't break the functionality that you use. Your boss would prefer 'probably not exploitable' to 'broken but fixing it now'. Best bet is to just restrict access to the webgui and SSH until 9.2.1.8 (if your are feeling paranoid).

 

[TFS_Rein]

The Systems are definitely not exposed to the internet in anyway, nor does anyone outside of IT have any access to the web gui or shell so it should be fine. Thanks for the input

 

[bestboy]

There will be a 9.2.1.8 and it will have the bash fix (as well as the TCP SA fix from a week or so ago)

Uhm... what's wrong with the selective acks?

 

[dkran]

I'm honestly surprised that in 20 years, nobody has discovered
env x='() { :;};

You think that would have been "fuzzed out" by now by some vulnerability scanner

 

[jgreco]

Anybody see an issue with just removing permissions to the bash shell like a chmod 000? This should help fix the issue until it's patched in the next release yes? And am I correct in saying that it's not used by anything except if a user is configured to use bash as their main shell?

If I use the command to test for the vulnerable bash versions it returns vulnerable. The system is a production system and my boss would prefer "not exploitable" vs "highly unlikely to be exploited" :)

I would prefer comments from the dev team about whether or not bash is called anywhere.

chmod 000, or, better, removing bash, is a fine remediation as far as I can tell.

It is reasonable to note that the "test" for vulnerable bash versions is marginally useless. What really needs to be analyzed is whether or not there exists a vector to call bash with a vulnerable environment. One could very reasonably argue that simply having a shell on a UNIX box makes it "vulnerable" for definitions of "vulnerable" that approximate "can run arbitrary commands"; there are numerous stack overrun exploits over the years for Internet facing services that rely on being able to get /bin/sh to be executed. So one of our jail design considerations here is to make sure that the contents of a jail do not require (and do not include) /bin/sh, which makes generic exploits substantially more difficult.

Or, put differently, I can actually make virtually ANY dynamically linked executable vulnerable (to some degree) if I am given a free hand with the environment. The attack surface of a shell executable is just much larger.

 

[ewhac]

I'd like to see, "FreeNAS Does Not Have the Shellshock Vulnerability*" posted on the site a little more prominently.

(*): With the caveat that third-party plugins may install vulnerable software, including bash. Some of the plugins for pfSense, for example, include bash binaries.

 

[anodos]

It's funny how much more riled up people are here about this bug than that critical remote code execution vulnerability in nmbd a couple of weeks back. :)

 

[bloomo]

I'm just glad it's being discussed and we have the smart guys on the FreeNAS team on our side. Thanks to everyone working on this behind the scenes.

 

[cyberjock]

For the record, bash is used for the WebGUI's shell. Just go to the shell and do "echo $SHELL". I cannot vouch if it has the security vulnerability or not and I can't (and probably wouldn't if I could) vouch for if 9.2.1.8 is going to happen as a result (in whole or in part because of this vulnerability).

Sorry, I'm not the man with the info. :p

The reality is that comments like what ewhac aren't generally made for appliance-like systems. FreeNAS is also open source and freely available. So anyone with *true* desire to know answers simply needs to be able to know the answer themself. Not to directly attach ewhac, but this kind of question (while very valid) can quickly turn into a discussion about "I expect other people to feed me vice feeding myself". If you want the answers they are definitely available as the code is open. What you should *really* be doing is flaming the living f*ck out of those routers and other closed-source devices that are derived from linux for answers. They are almost certainly NOT making their code available, and therefore you should *absolutely* be expecting them to provide the answer and the fix- because you don't have access to the necessary code to validate this for yourself no matter what.

Big picture, FreeNAS shouldn't be exposed to the internet anyway. This is *very* well documented. If you've done this, you kind of deserve to be in the dark. Sweat a little and be upset. Maybe you'll learn that you shouldn't be doing stupid things and expecting other people to jump to your rescue because you don't want to do what is right. ;)

Knowledge is power, and if you don't have the knowledge don't expect me to jump to your rescue because you didn't try to empower yourself. ;)

*cough*

https://bugs.freenas.org/projects/f...ions/4771be6243293f78a6b4686d2c19d8ce676ba69c

https://bugs.freenas.org/projects/f...ions/e17fe1e5f6b37b0b67f7c879b8c0ce8ebd762f01

https://bugs.freenas.org/projects/f...ions/b1306b8bb75db02c0ac310e667110bf98339036f

*cough*

 

[bloomo]

For the record, bash is used for the WebGUI's shell. Just go to the shell and do "echo $SHELL". I cannot vouch if it has the security vulnerability or not and I can't (and probably wouldn't if I could) vouch for if 9.2.1.8 is going to happen as a result (in whole or in part because of this vulnerability).

Sorry, I'm not the man with the info. :p

The reality is that comments like what ewhac aren't generally made for appliance-like systems. FreeNAS is also open source and freely available. So anyone with *true* desire to know answers simply needs to be able to know the answer themself. Not to directly attach ewhac, but this kind of question (while very valid) can quickly turn into a discussion about "I expect other people to feed me vice feeding myself". If you want the answers they are definitely available as the code is open. What you should *really* be doing is flaming the living f*ck out of those routers and other closed-source devices that are derived from linux for answers. They are almost certainly NOT making their code available, and therefore you should *absolutely* be expecting them to provide the answer and the fix- because you don't have access to the necessary code to validate this for yourself no matter what.

Big picture, FreeNAS shouldn't be exposed to the internet anyway. This is *very* well documented. If you've done this, you kind of deserve to be in the dark. Sweat a little and be upset. Maybe you'll learn that you shouldn't be doing stupid things and expecting other people to jump to your rescue because you don't want to do what is right. ;)

Knowledge is power, and if you don't have the knowledge don't expect me to jump to your rescue because you didn't try to empower yourself. ;)

*cough*

https://bugs.freenas.org/projects/f...ions/4771be6243293f78a6b4686d2c19d8ce676ba69c

https://bugs.freenas.org/projects/f...ions/e17fe1e5f6b37b0b67f7c879b8c0ce8ebd762f01

https://bugs.freenas.org/projects/f...ions/b1306b8bb75db02c0ac310e667110bf98339036f

*cough*

Yep. No doubt that your gateway should be your line of defense against the internet. If you're open to prying eyes then you kinda dropped your guard already.

Just for fun, if you want to test if your FreeNAS is vulnerable to shellshock, you can run:

Code:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

If it returns "vulnerable hello" then you are. If you get a "...warning... ignoring function definition attempt...", you are not.

 

[jgreco]

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.