BASH exposure expressed as bigger than Heartbleed<SOLUTIONS>

[watchdog]

Updated for dpup487 here

This might work on other pups, not sure with which ones it would be compatible though, you could test with pfix=ram

It seems good for puppy 4.3.2, slacko 5.3.3, lucid and even wary-racy.

[Terryphi]

For those with wary/racy here is bash 3.0.17 compiled from BK's source and the gnu patch, in Racy 5.5

Thanks mavrothal. Works for me without any problems. Great to see Racy/Wary being supported with security patches.

[James C]

Concern over Bash vulnerability grows as exploit reported “in the wild

[mavrothal]

For a more puppy-relevant view

Code: Select all

With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services.

In simple terms, unless you are running a server or allow any kind of remore-login to your puppy, you are safe even without updating your bash.
If you are running servers and you are not updating your machine regularly and be on top of it in general, you are destine for trouble, bash or not bash.

But even if you have some small personal server running, what are the odds of being targeted among the millions of IP addresses?.
To put things in prospective the probability to be in a car accident next year, is 1/~10000! But you are still out in the streets without freaking out (I hope...)
So looks like a lot of hype and FUD that will fizz in a couple more days.

In my mind the only relevant puppy question is:
is the forum (and other puppy-related) server(s) patched?

[James C]

I was assuming Puppy users would notice phrases like:

....expressing fears that it could be used for an Internet "worm" to exploit large numbers of public Web servers......

.....Any organizations or users with unpatched Linux servers are vulnerable to hackers running unauthorized code....

[James C]

Updated for dpup487 here

This might work on other pups, not sure with which ones it would be compatible though, you could test with pfix=ram

Works in Upup Raring 3.9.9.2 as well. Thanks.

[keniv]

Updated for dpup487 here

This might work on other pups, not sure with which ones it would be compatible though, you could test with pfix=ram

Also works with Sulu 002 which is one of the updated versions of Lucid 528.
I did try it first in pfix=ram and I also backed up my save file before I tried it for real.

Thanks,

Ken.

[James C]

Everything you need to know about the Shellshock Bash bug

http://www.troyhunt.com/2014/09/everyth ... about.html

Remember Heartbleed? If you believe the hype today, Shellshock is in that league and with an equally awesome name albeit bereft of a cool logo (someone in the marketing department of these vulns needs to get on that). But in all seriousness, it does have the potential to be a biggie and as I did with Heartbleed, I wanted to put together something definitive both for me to get to grips with the situation and for others to dissect the hype from the true underlying risk.

In all likelihood, we haven’t even begun the fathom the breadth of this vulnerability. Of course there are a lot of comparisons being made to Heartbleed and there are a number of things we learned from that exercise. One is that it took a bit of time to sink in as we realised the extent to which we were dependent on OpenSSL. The other is that it had a very long tail – months after it hit there were still hundreds of thousands of known hosts left vulnerable.

But in one way, the Heartbleed comparison isn’t fair – this is potentially far worse. Heartbleed allowed remote access to small amount of data in the memory of affected machines. Shellshock is enabling remote code injection of arbitrary commands pre-auth which is potentially far more dire.

[James C]

Frequently Asked Questions about the Shellshock Bash flaws

https://securityblog.redhat.com/2014/09 ... ash-flaws/

The recent few days have been hectic for everyone who works in the Linux/Unix world. Bash security flaws have rocked the globe leaving people confused, worried, or just frustrated. Now that the storm is over and patches are available for most operating systems, here are the answers to some of the common questions we’ve been asked:

[prehistoric]

Instead of waiting for patches to bash itself to be tested, why not simply alter the scripts which call these programs to call a known-good shell which does not allow such exploits in order to have it call the few programs which access the internet directly.?

Bash was a good shell 2 days ago and is today after patching.
There is no way BTW to know that current "good shells" will remain good.

You are actually making my case for me. Switching from, e.g. Bash to Dash, leaves you with a very powerful scripting capability which may be exploited at a later date. Patching bash to eliminate a scripting vulnerability risks breaking scripts used all through Puppy variants. To use a phrase seen elsewhere in the discussion, this process will have "a very long tail".

What I'm trying to say is that launching programs which might, in some way we have not imagined, be fed scripts by a source outside our control with a shell having all the scripting capabilities of full bash is asking for trouble. I'm proposing that only those programs which might be affected by scripts sent over the Internet, like browsers and some email programs, be launched using a shell which never had the extensive scripting and environment manipulation supported by bash. You can't exploit what was never put in in the first place.

Having seen a wide variety of cross-site scripting and code injection attacks, like SQL code injection, I've gone to running browsers as a restricted user, "spot". It would also make sense to launch these browsers with less powerful shell programs. An attack which exploits a vulnerability in bash, or another powerful shell, will then have another level to work through before it can even get to bash. The cost in execution speed will be limited to the number of times we launch programs like browsers, email, etc.

This does not require changing bash throughout the system, and possibly breaking things we had not considered. Such a change can be made without compiling, by changing the way a limited number of programs like browsers are invoked, and will not require extensive testing to see if we broke other scripts.

All new versions should use the latest bash, but there is no need for older systems to undergo extensive alterations.

[sheldonisaac]

Slacko "updates manager" should have slacko users covered. It's in the menu under "Set up". Once installed, restart X (equivalent to logout, login). Or reboot if extra paranoid CORRECTION: it doesn't because a puppy package covers bash. HOWEVER, still run "updates manager" as this refreshes the "patches" repo database.

Enable "patches" repo in PPM if not already. Then search "bash". Install (make sure from "patches repo"), restart X.

I've tried, but can't get a "patches repo".
Help, please.
I'm quite inexperienced with Slacko, 5.70

Thank you,
Sheldon

[watchdog]

Slacko "updates manager" should have slacko users covered. It's in the menu under "Set up". Once installed, restart X (equivalent to logout, login). Or reboot if extra paranoid CORRECTION: it doesn't because a puppy package covers bash. HOWEVER, still run "updates manager" as this refreshes the "patches" repo database.

Enable "patches" repo in PPM if not already. Then search "bash". Install (make sure from "patches repo"), restart X.

I've tried, but can't get a "patches repo".
Help, please.
I'm quite inexperienced with Slacko, 5.70

Thank you,
Sheldon

I had already installed the package suggested by jamesbond:

http://www.murga-linux.com/puppy/viewto ... 627#800627

In PPM it seems the latest. If you have problems with Updates Manager just download and install it.

[James C]

.

[cimarron]

Looks like a more complete fix has been released:
[url=http://arstechnica.com/security/2014/09 ... first-fix/]New “Shellshock

[mikeslr]

Hi All,

dejan555's pet, http://www.murga-linux.com/puppy/viewto ... 678#800678, also works in Carolina 1.2

Thanks dejan555.

The above was written before I checked the Carolina thread. Geoffrey has also responded to the threat. A Carolina-specific BASH update pet can be obtained thru Carolina's Package Management. It's available here: http://smokey01.com/carolina/pages/recent-repo.html It will probably also work in Racy and Saluki. Thanks Geoffrey.

mikeslr

[Geoffrey]

Edit: the latest is 030
Compiled the latest patch 026 in Carolina, I used instructions from here, needs modifying to suit as default is installed to /usr/local, change the 25 to the latest patch that's available which at the moment is 26.

Code: Select all

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
#download all patches
for i in $(seq -f "%03g" 0 25); do wget     http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz 
cd bash-4.3
#apply all patches
for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done
#build and install
./configure && make && make install
cd .. 
cd ..
rm -r src

Code: Select all

# cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
date
cat: /tmp/echo: No such file or directory

b̶a̶s̶h̶-̶4̶.̶3̶.̶2̶6̶-̶1̶.̶p̶e̶t̶ (REMOVED)

b̶a̶s̶h̶-̶4̶.̶3̶.̶2̶8̶-̶1̶.̶p̶e̶t̶ (REMOVED)

b̶a̶s̶h̶-̶4̶.̶3̶.̶2̶9̶-̶1̶.̶p̶e̶t̶ (REMOVED)

bash-4.3.30-1.pet

b̶a̶s̶h̶_̶D̶O̶C̶-̶4̶.̶3̶.̶2̶6̶-̶1̶.̶p̶e̶t̶ (REMOVED)

b̶a̶s̶h̶_̶D̶O̶C̶-̶4̶.̶3̶.̶2̶8̶-̶1̶.̶p̶e̶t̶ (REMOVED)

b̶a̶s̶h̶_̶D̶O̶C̶-̶4̶.̶3̶.̶2̶9̶-̶1̶.̶p̶e̶t̶ (REMOVED)

bash_DOC-4.3.30-1.pet

b̶a̶s̶h̶_̶N̶L̶S̶-̶4̶.̶3̶.̶2̶6̶-̶1̶.̶p̶e̶t̶ (REMOVED)

b̶a̶s̶h̶_̶N̶L̶S̶-̶4̶.̶3̶.̶2̶8̶-̶1̶.̶p̶e̶t̶ (REMOVED)

b̶a̶s̶h̶_̶N̶L̶S̶-̶4̶.̶3̶.̶2̶9̶-̶1̶.̶p̶e̶t̶ (REMOVED)

bash_NLS-4.3.30-1.pet

[michaellowe]

HI everyone It was suggested to me by cimarron to apply this patch found at: https://launchpad.net/~ubuntu-security- ... ld/6408041 and so I did but I have an i686 architecture. I applied the patch and rebooted. how will I know if its working? thanks in advance

[Geoffrey]

@michaellowe

Type

Code: Select all

bash --version

in the terminal, you should see as shown below, which in my case is the Carolina build i686

Code: Select all

GNU bash, version 4.3.26(1)-release (i686-pc-linux-gnu)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[michaellowe]

@ Geoffrey

please find attached a screen shot of my bash version.
I'm on precise 5.7.1 with kernel 3.9.11



am I good to go? cheers

[cimarron]

As I posted above, to check if the new (second) fix is working, paste this line into the terminal:

Code: Select all

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

If your system is vulnerable, the time and date information will be output on the screen (and a file called /tmp/echo will be created):

Code: Select all

bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
Fri Sep 26 11:49:58 GMT 2014

If your system is not vulnerable, you will see output similar to:

Code: Select all

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