# Bash Vulnerability

## jlpoole

I haven't seen any posting of this in the forums and so offer this up:

http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-anything-with-nix-in-it/

----------

## 666threesixes666

http://seclists.org/oss-sec/2014/q3/649

yup, disable ssh or update....

<shamus397> try this: LC_TIME='() { :;}; echo vulnerable' ssh <your systems hostname here>Last edited by 666threesixes666 on Wed Sep 24, 2014 11:25 pm; edited 1 time in total

----------

## jlpoole

I had several servers that were vulnerable.  Updating to 4.2_p48 should make you safe from this one.  4.2_p45 is vulnerable.

 *Quote:*   

> 
> 
>  # eix app-shells/bash
> 
> [U] app-shells/bash
> ...

 

----------

## Kilteroff

I'm sorry, how do you do this? My Emerge&Portage skills are still in devel -_-

----------

## jlpoole

 *Kilteroff wrote:*   

> I'm sorry, how do you do this? My Emerge&Portage skills are still in devel -_-

 

```
emerge --sync

emerge app-shells/bash

```

----------

## The Doctor

That should be 

```
emerge -1 app-shells/bash
```

Note the -1. Cluttering the world file is a bad idea.

----------

## Kilteroff

That was the first thing I did, still app-shells/bash-4.2_p45 though :/

----------

## eccerr0r

https://forums.gentoo.org/viewtopic-t-1000670-highlight-.html

You can also just do a regular world update.

Use --oneshot to upgrade packages if you didn't explicitly emerge them... This will help out portage package messes down the road - though in this case, bash is unlikely to get orphaned...

----------

## Kilteroff

Well I followed the instructions and ran emerge --ask --oneshot --verbose ">=app-shells/bash-4.2_p48" 

Now I have app-shells/bash-4.3_p24-r1

Scurry stuff. Thanks for the help  :Smile: 

----------

## wuzzerd

Awesome: Gentoo has already handled this problem.  Free beer for the devs!!

----------

## sk3l

 *666threesixes666 wrote:*   

> http://seclists.org/oss-sec/2014/q3/649
> 
> yup, disable ssh or update....
> 
> <shamus397> try this: LC_TIME='() { :;}; echo vulnerable' ssh <your systems hostname here>

 

Seems like patching should take priority, but is disabling sshd really necessary? FWICT only sshd configs with ForceCommand enabled are vulnerable? If you're not running GIT or SVN or the like your SSH may be OK. Please correct me if I'm mistaken.

----------

## tld

 *wuzzerd wrote:*   

> Awesome: Gentoo has already handled this problem.  Free beer for the devs!!

 

It also appears that the version in Gentoo seems to have addressed the fact that the original fix was incomplete:

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

After updating:

```
env X='() { (a)=>\' sh -c "echo date"; cat echo

sh: X: line 1: syntax error near unexpected token `='

sh: X: line 1: `'

sh: error importing function definition for `X'

date

cat: echo: No such file or directory

```

However, on CentOS 6, the updated version which is supposed to be fixed appears to prevent the behavior as suggested in the original test, but does NOT deal with the above example:

```
env X='() { (a)=>\' sh -c "echo date"; cat echo

sh: X: line 1: syntax error near unexpected token `='

sh: X: line 1: `'

sh: error importing function definition for `X'

Thu Sep 25 11:11:58 EDT 2014

```

Scary stuff.  Gentoo devs are on top of this for sure!

Tom

----------

## Duncan Mac Leod

 *wuzzerd wrote:*   

> Awesome: Gentoo has already handled this problem.  Free beer for the devs!!

 

YES!! Free beer for the devs!! I love you!!!  :Cool: 

----------

## darookee

I have to systems running gentoo, I updated them both as in https://forums.gentoo.org/viewtopic.php?p=7623082#7623082

One has GNU bash, version 4.2.48(1)-release (x86_64-pc-linux-gnu)

The other GNU bash, version 4.3.24(1)-release (x86_64-pc-linux-gnu)

When I run the test on the first I get this:

```

root:spork:~> env X='() { (a)=>\' /bin/bash -c "echo date"; cat echo

/bin/bash: X: line 1: syntax error near unexpected token `='

/bin/bash: X: line 1: `'

/bin/bash: error importing function definition for `X'

date

Thu Sep 25 23:21:21 CEST 2014

root:spork:~>

```

And on the second it is the same. Am I missing something? It looks like it is not fixed...?

----------

## tld

 *darookee wrote:*   

> And on the second it is the same. Am I missing something? It looks like it is not fixed...?

 

Actually I think you're correct.  I noticed earlier that the updated Gentoo version had no patch other than the one known to be incomplete.

I think the above behavior I'm seeing, where I don't appear to have that issue, may possibly be because it's on an older x86 machine(??):

```
equery list bash

 * Searching for bash ...

[IP-] [  ] app-shells/bash-4.2_p48-r1:0

uname -a

Linux dell2 3.14.16-gentoo #1 SMP PREEMPT Tue Aug 19 11:25:32 EDT 2014 i686 Intel(R) Pentium(R) 4 CPU 2.53GHz GenuineIntel GNU/Linux

env X='() { (a)=>\' sh -c "echo date"; cat echo

sh: X: line 1: syntax error near unexpected token `='

sh: X: line 1: `'

sh: error importing function definition for `X'

date

cat: echo: No such file or directory

```

At least that's the only explanation I can imagine offhand.  As you can see it's not occurring for me, but as far as I can see, there currently is no fix available yet for that one.

----------

## eccerr0r

I've seen multiple incantations of the bug detection script around, it looks like the one with bad syntax is the worrysome one.

host4248r1 is x86 running bash4.2_p48r1 -- I also have x86_64 and behaves the same.

host4245 is x86_64 running bash4.2_p45

```
host4248r1$ bash

host4248r1$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

bash: warning: x: ignoring function definition attempt

bash: error importing function definition for `x'

this is a test

host4248r1$ exit

exit

host4248r1$ bash

host4248r1$ rm -f echo

host4248r1$ env X='() { (a)=>\' sh -c "echo date"; cat echo

sh: X: line 1: syntax error near unexpected token `='

sh: X: line 1: `'

sh: error importing function definition for `X'

date

cat: echo: No such file or directory

host4248r1$

```

The second one seems to be creating an improper function but oddly bash is still parsing it, but nevertheless it should not be executing it like on this vulnerable machine:

```
host4245$ bash

host4245$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

vulnerable

this is a test

host4245$ exit

exit

host4245$ bash

host4245$ rm -f echo

host4245$ env X='() { (a)=>\' sh -c "echo date"; cat echo

sh: X: line 1: syntax error near unexpected token `='

sh: X: line 1: `'

sh: error importing function definition for `X'

Thu Sep 25 17:43:15 MDT 2014

```

In any case it should not print out the date.  Then again any function declaration appears to do rudimentary parsing:

```

host4248r1$ b() { (a)=> }

bash: syntax error near unexpected token `='

```

----------

## eccerr0r

Just want to report that I had two hosts from "security companies" probe my server for shellshock through httpd.  At least they made it somewhat obvious; there are more subtle ways of doing it...

----------

## darookee

I just checked again after updating one host to 4.3_p25-r1 and, 'magically', both host, the on running 4.2_p48-r1 and the other don't show the 'vulnerable' behavior, even though I didn't do anything on the bash-4.2 host... Funny...

```

$ equery list bash

[IP-] [  ] app-shells/bash-4.2_p48-r1:0

$ uname -a

Linux spork 3.10.17-gentoo #1 SMP Thu Nov 21 02:14:03 CET 2013 x86_64 AMD FX(tm)-4100 Quad-Core Processor AuthenticAMD GNU/Linux

$ env x='() { :;}; echo vulnerable' /bin/bash -c "echo this is a test"

/bin/bash: warning: x: ignoring function definition attempt

/bin/bash: error importing function definition for `x'

this is a test

```

```

$ equery list bash

[IP-] [  ] app-shells/bash-4.3_p25-r1:0

$ uname -a

Linux mirinda 3.8.13 #3 SMP Sun Dec 15 21:23:34 CET 2013 x86_64 AMD Athlon(tm) II X2 240 Processor AuthenticAMD GNU/Linux

$ env x='() { :;}; echo vulnerable' /bin/bash -c "echo this is a test"

/bin/bash: warning: x: ignoring function definition attempt

/bin/bash: error importing function definition for `x'

this is a test

```

----------

## eccerr0r

looks like bash-4.2_p49 is available on portage now, which is the same as Gentoo's p48-r1 (which got obsoleted).

----------

## ChrisJumper

The show must go on: app-shells/bash-4.2_p50 is available now.

----------

## baragoon

 *ChrisJumper wrote:*   

> The show must go on: app-shells/bash-4.2_p50 is available now.

 

But still vulnerable...

Not vulnerable to CVE-2014-6271 (original shellshock)

Not vulnerable to CVE-2014-7169 (taviso bug)

/root/t.sh: line 18:  2692 Segmentation fault      bash -c "true $(printf '<<EOF %.0s' {1..79})" 2> /dev/null

Vulnerable to CVE-2014-7186 (redir_stack bug)

Test for CVE-2014-7187 not reliable without address sanitizer

Variable function parser inactive, likely safe from unknown parser bugs

----------

## patrix_neo

Redhat offered SJVN @ zdnet some tip how to check if your bash is vulnerable or not. It includes talk abut the CVE-2014-7186 bug.

http://www.zdnet.com/shellshock-better-bash-patches-now-available-7000034115/

Mine: bash-4.2_p50 made the tests.

Test 1

 *bash tests#1@zdnet wrote:*   

> 
> 
> env 'x=() { :;}; echo vulnerable' 'BASH_FUNC_x()=() { :;}; echo vulnerable' bash -c "echo test"
> 
> 

 

 *bash result#1@zdnet wrote:*   

> 
> 
>     bash: warning: x: ignoring function definition attempt
> 
>     bash: error importing function definition for `BASH_FUNC_x'
> ...

 

NOTE: With bash-4.2_p50, bash replied with: test only. Good or bad, I don't know.

Test 2

 *bash tests#2@zdnet wrote:*   

> 
> 
> cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
> 
> 

 

 *bash result#2 wrote:*   

> 
> 
>     date
> 
>     cat: /tmp/echo: No such file or directory
> ...

 

----------

## geeksheik

This may deserve a new thread; it seems that the bash ebuild is currently corrupted.  I did the system update several days ago, and there have been already a few new releases in the meantime.  Now the ebuild seems to be broken or corrupted.  I'm guessing that it's due to a transfer error between servers, but this is the type of message that one would see if there is intentional manipulation.

 *Quote:*   

> 
> 
> Starting emerge -u -D -v -N world on 20141002_133808...
> 
> These are the packages that would be merged, in order:
> ...

 

 *Quote:*   

> 
> 
> -> cat /usr/portage/metadata/timestamp.chk 
> 
> Thu, 02 Oct 2014 11:30:01 +0000
> ...

 

I already re-synced once and got the same result.Last edited by geeksheik on Sat Oct 04, 2014 2:31 pm; edited 1 time in total

----------

## gerard27

Had the same problem.

Resynced and it compiled properly.

Gerard.

----------

## patrix_neo

Security wise I feel undressed..Thanks for every effort though. I will reboot soonish.

----------

## geeksheik

The corrupted ebuild was fixed the same day.

A big thanks to the maintainers (both Gentoo & upstream); I'm sure it's not an easy time at the moment.

----------

## eccerr0r

Arrgh...  It's the broken again shell!

----------

## ct85711

At least the one good thing about these vulnerabilities in bash; is that it's getting a lot closer review; finding all these other issues that should have been fixed a long time ago.  Hopefuly someone is also taking a look on zsh, dash, etc for similar issues.

----------

## eccerr0r

It almost looks like a house of cards there... It looks like a whole bunch of bugs that were discovered related to environment function passing (which can be a good thing) one after another...

Is function passing a feature specific to bash?  I'd imagine this shouldn't be a unique feature.  There have been tons of restrictions of what can and can't be passed (variables, exported variables, etc.), and having them pass can make scripts run considerably faster...

----------

## ct85711

my thoughts on function passing, is more of the data being used in one environment shouldn't be idlely used outside of it's environment.  So any data used in one function shouldn't be accessible outside of that function, unless it was explicitly passed onto another function.  Now a function jumping to another, sound more like a uncontrolled operation than anything else (like how do you know every time, it will always jump to that function, and not some rogue one that was injected into the tree above it).

*Note* I wouldn't consider myself as a programmer, more of a hobbyist; as I'm not too skilled on programming yet.

----------

## Hu

Function inheritance may not be unique to bash, but there is no standard on how to do it, so any other shells that do it likely do it differently from bash, especially now that bash has several different ways of doing it, depending on which patch level you run.

I believe I saw a comment on one of the mailing lists that the reason this was so broken is that the bash parser was never considered a security boundary until Shellshock hit.  The assumption was always that by the time the user could feed it bad input, the shell was running and ready to do as you asked, so the only thing you could achieve by feeding it bad input was to crash the shell.  Shellshock was a problem because the parser consumed user input while running with fewer restrictions than the user would have when the shell finished initializing and began accepting interactive input.

----------

## ChrisJumper

At the next Time index tick, your Bash should have Version: 4.2_p53.

----------

## eccerr0r

The http attacks have dropped down a lot...   I got one yesterday and it's sort of disguised as beneficial fix but how could they fix it?  You can't fix bash without root...

And as expected... it's yet another command and remote control irc bot.

Oh well.

----------

## patrix_neo

The last two weeks I have been rebooting my system (just-in-case) more times than I usually do in the span of months consuming a big part of a year.

I feel that necessary reboots has become a more frequent behavior for us linux folks.

But, as I have made it to believe, this bash problem was a security issue meant to happen. Has been overlooked, that is.

Anyway..

----------

## ct85711

just wondering, why are you needing to reboot so frequently?  I've been leaving my computer on all the time, and I only reboot when I switch OS (lately, been often for class), otherwise I haven't ever really needed to reboot.  You can't say because of all these security issues; as there's always some new security issue for some software nearly daily.  That part is a matter of life for any OS, (Windows, you just don't get told, and doesn't get fixed till several months later on).  Just like, there some new version of software out.  Bash by it's self, is the easiest thing in reguards to updating to the new version installed; most you need to do is reload the terminal window/log out and log back in, and it's using latest bash (that is installed).

The point I am getting at; is, there's no point worrying about some security issue.  There will always be some new one; the most you can do is update your software, monitor your system(s) and continue with your life (it's not going to end, about something so minor).  The developers here (including for most of the Linux environment) will adress the security issues as fast as they can and you should have access to a patch relatively fast.

----------

## patrix_neo

 *ct85711 wrote:*   

> just wondering, why are you needing to reboot so frequently?

 

I can only speak for myself, but I have understood that processes, like underlying services as login, boot up processes are depending on bash/sh.

And there has been 3 new bash security updates.

So, in function of time consuming, a reboot is quite ok, secure in terms of avoiding wtf-did-I-forgot-that?, and maby lazy.

And then there are other occasions I do reboots. Among others are

kernel-upgrades 

glibc

----------

## UberLord

 *patrix_neo wrote:*   

> I can only speak for myself, but I have understood that processes, like underlying services as login, boot up processes are depending on bash/sh.

 

They use bash, but do not persist it, they reload it on demand.

So no, rebooting to upgrade bash is not needed.

----------

## patrix_neo

 *UberLord wrote:*   

>  *patrix_neo wrote:*   I can only speak for myself, but I have understood that processes, like underlying services as login, boot up processes are depending on bash/sh. 
> 
> They use bash, but do not persist it, they reload it on demand.
> 
> So no, rebooting to upgrade bash is not needed.

 

Thank you for the input. Not so much a chocking news for me either. Me rebooting often, I now understand is more of a me-problem.

But to clarify for my tiny brain, when you say reload on demand, does than involve a manual reload?

I knew back when I did an init 1 and then an init 3 to restart everything but, I think, the kernel and the glibc. 

I don't know if that's still true with the OpenRC of today.

----------

## UberLord

 *patrix_neo wrote:*   

> [But to clarify for my tiny brain, when you say reload on demand, does than involve a manual reload?

 

No.

Init will do this for example

/etc/init.d/foo

-> /sbin/runscript

-> /bin/sh

-> /bin/bash

-> foo

foo them forks as a daemon or something, everything else unloads

If a daemon internals calls out to sh or bash it will be like running a program which 99% of the time will close again promptly.

So nothing manual in reloading is required.

 *Quote:*   

> 
> 
> I knew back when I did an init 1 and then an init 3 to restart everything but, I think, the kernel and the glibc. 
> 
> I don't know if that's still true with the OpenRC of today.

 

Should still work on Gentoo/Linux.

----------

## eccerr0r

I just saw a few people sending shellshocks to me via http after about 2 weeks of silence.

Not quite forgotten just yet...

----------

