BASH exposure expressed as bigger than Heartbleed<SOLUTIONS>

[SFR]

@Mick: Dunno why, but Slackware's bash packages render HOME/END keys unusable in terminal (urxvt, LXTerminal, VTE).
The same happened with bash compiled by myself.
A workaround is to append this to /etc/inputrc:

Code: Select all

"\e[1~": beginning-of-line      # Home Key
"\e[4~": end-of-line            # End Key

Greetings!

Another, even more annoying, issue with Slackware's bash binary: when I am typing a long line, that exceeds the right margin, it no longer wraps to the next line, but instead some maddening, horizontal scroll mode turns on.
It's impossible to highlight & copy such over-extended line!

Ok, it took me some time and nerves, but long story short: after I compiled bash with '--with-curses' (also literally) both issues are gone.
All patches applied, pkg for Slacko 32bit: bash-4.1.17.pet.
MD5: 65d5f2f8c8447a1e87936e3976d5e947 bash-4.1.17.pet

EDIT: updated to the latest (#14) patch.
EDIT2: updated to the latest (#17) patch.

Greetings!

[keniv]

dejan555 wrote

New version for dpup487, should work with same pups that the previous one was reported to work...

I tested on test savefile again (after removing first fix). Now on normal savefile which seems OK. So again working in Sulu 002 (updated version of Lucid 528).

Thanks again,

Ken.

[prehistoric]

Applied dejan555 second version to stemsee's Puppy Precise 5.7.1 and ran cimarron's test script in console. So far, so good.

We need more testers, and we have a problem explaining the requirements to people who do not regularly compile code, and are not aware of the genealogy of the Puppy they are running. It took a while for me to decide that a 32-bit .deb package would work, and finding correct binaries on Ubuntu sites is currently challenging. When I started I was not sure if I was running a 32-bit PAE kernel or 64-bit kernel. For those with less experience this would be a serious obstacle.

We also need better explanations of the ancestry of the many Pupplets out there. Not everyone keeps up with code names used by Ubuntu, Debian or Puppy.

At first I thought the fix had failed, because I also got the syntax warning in cimarron's post. Then I realized the syntax error was necessary to run the test. The important thing was that no output file was created as a result. Before testing becomes more widespread we need to explain such details so that ordinary users don't have to puzzle this out on their own.

Any feature of open source code which can sit there for a couple of decades without anyone noticing has to be pretty obscure. This fits that description.

[anikin]

As this article: http://cloudgames.com/blog/fix-bash-exp ... u-apt-get/
implies, older debian/ubuntu based systems, can use bash from the current stable release. No need to search/wait for special, "old" versions. Makes sense.

[rolf]

Here is bash 3.0.18 for wary/racy 5.5 that also passes the

Code: Select all

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

test.

I happen to be running a small webserver in Puppy 4.31 small on an Igel thin client.
http://www.murga-linux.com/puppy/viewto ... 271#508271

Not knowing how to switch shells for the vulnerable server functions, I'm grateful for this. Thanks.

Code: Select all

# bash -version
GNU bash, version 3.00.18(1)-release (i486-pc-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.
# 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
# cat /etc/puppyversion 
431

[Kester]

As suggested by Cimarron in an earlier post, I typed the following into the terminal to test Bash in my installation:
cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
The result I got was:
env: can't execute 'Bash': No such file or directory
cat: /temp/echo: No such file or directory
Hopefully, although the phrasing is not identical to that Cimarron shows for a non-vulnerable system, it would seem that as no date is shown, Bash is not vulnerable on my system at present. I would be grateful if the Puppy experts out there could confirm this (or otherwise) as I am still fairly naive when it comes to the under the bonnet/hood workings of Linux systems.

Taking Prehistoric's comment ("Before testing becomes more widespread we need to explain such details so that ordinary users don't have to puzzle this out on their own."), as one of those 'ordinary' users, I would appreciate any explanation in not too technical language.

I have considered removing Puppy Precise 5.7.1 from my dual boot (XP Pro) system by booting up my XP installation disc, opening the 'Repair' option and running 'fixmbr'. I would then return to using live discs for Puppy but perhaps there is no need to take such a drastic step - it's a question of lack of confidence caused by a lack of knowledge on my part. I'm more confident with Windows XP because I know it better but like Puppy very much and decided on dual booting for security reasons when Microsoft support for XP finished - I though I use Puppy for the bulk of my internet activity, so this Bash issue is a little ironic.

[prehistoric]

@Kester,

You don't need to do anything to invoke Bash from a console. It is the default command-line processor. If you tried to execute "Bash" you would run into the problem that a Unix/Linux console is case sensitive, so "Bash" is different from "bash", which is generally invoked automatically as "/bin/sh" without you having to specify anything. You may not even find the name "bash" in your /bin directory.

You can also save yourself some tricky typing by simply highlighting the test command in your browser, directly from this web page, and then doing a "middle-click" in your console window. This will copy highlighted text without needing a cut-and-paste.

[anikin]

[quote]I appreciate the effort made in patch bash43-026, but this patch doesn't even BEGIN to solve the underlying shellshock problem. This patch just continues the "whack-a-mole" job of fixing parsing errors that began with the first patch. Bash's parser is certain have many many many other vulnerabilities; it was never designed to be security-relevant…John Haxby recently posted that "A friend of mine said this could be a vulnerability gift that keeps on giving.

[James C]

Shellshock vulnerability affects majority of Internet servers and devices; get technical information here

Scan your servers........

http://www.trendmicro.com/us/security/s ... index.html

[rolf]

Shellshock vulnerability affects majority of Internet servers and devices; get technical information here

Scan your servers........

http://www.trendmicro.com/us/security/s ... index.html

Well, I followed instructions and got all Pass. I guess this is thanks to the patched bash-3.00.18(1), tyvm, but have to trust trendmicro for the efficacy of the test. Also, the whack-a-mole issue still obtains, iianm.
Thanks.

[James C]

Shellshock: All You Need to Know About the Bash Bug Vulnerability | Symantec

https://www.youtube.com/watch?v=ArEOVHQu9nk

[quote]A new vulnerability has been found that potentially affects most versions of the Linux and Unix operating systems, in addition to Mac OS X (which is based around Unix). Known as the “Bash Bug

[anikin]

A couple posts back, there's a link to an article in ArsTechnica, the following is a comment from that link.

diddum wrote:
One thing that I would really like to know is a list of services I should shut down (like apache2) until this bash madness has been completely fixed.

Is there such a list of possibly affected services ?

Thanks,
a Debian user

If you are using at least Debian squeeze (6.0), you're actually probably in better shape than anyone using Red Hat. Debian links /bin/sh to /bin/dash, so unless a script or executable explicitly calls bash, you're safe.

If you use "ForceCommand" directives in ssh, you can't rely on these if you let your users run bash. (You are effectively letting them get un-restricted shell access instead). But I think you could mitigate this by forcing them to run /bin/sh instead (or let them run mksh it's significantly more user friendly). And if you don't use "ForceCommand" it doesn't matter.

dhclient runs shells scripts in /etc/dchp/dhclient-enter-hooks.d, /etc/dchp/dhclient-enter-hooks.d but unless something insane was done, it will execute them with /bin/sh unless the script explicitly calls bash.

telnet, rsh, also are good things to disable, but you shouldn't have been using them in the first place.

Check if you run any bash scripts out of inetd/xinetd (probably not).

I don't know there might be other stuff. But, on debian, you're actually relatively safe unless somebody didn't something really stupid. The problem is, you can't really be too sure somebody didn't do something really stupid.

Edit:

You should be careful about the login shells for users. If you have some user that really should be a system user with /bin/no-login, or /bin/False as their shell, but some reason needs an actually posix shell as their login shell, set it to /bin/sh, make user it's not /bin/bash

[prehistoric]

Just for anyone who might be confused about the difference between a test that fails and one that succeeds, here are the results I've reproduced from an installation of stemsee's Puppy Precise 5.7.1 using the pet produced by dejan555 to fix bash.
Before, fails:

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'
Sat Sep 27 21:55:35 EDT 2014
# 

After, succeeds:

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
#

The syntax error is reported in both cases because that is the way an attacker tricks the parser in bash into parsing code that has been added.

[Barkin]

Lucid Puppy 525 apparently fixed using this dejan555 pet ... "bash-4.3.26-1-i486-dpup487.pet" [437 KB]
on page ... http://www.murga-linux.com/puppy/viewtopic.php?p=800926#800926

[prehistoric]

@Barkin,

I actually prefer the more complicated test used by cimarron. The date function has to be executed to produce that new text, and a file created as a result. With the simple test you used I would worry that a mix-up in quoting gave me a false assurance that a vulnerable system was safe.

Added: I can now report that the fix for Fatdog 700 b1 (bash-4.2-x86_64-3.txz) works there, and that extracting the executable file from the tarball and copying it to /bin also works in Fatdog 630-631. (You need to do this manually because the package format has been changed between the 600 and 700 series.)

Here are James Bond's instructions copied from the 631 topic:

1. Get bash-4.2-x86_64-3.txz from 700 repo.
2. mkdir /tmp/xxx
3. cd /tmp/xxx
4. tar -xf /path/to/downloaded/bash-4.2-x86_64-3.txz
5. try to run ./bin/bash --version (version should be 4.2.49)
6. if this is good then cp ./bin/bash /bin

[Barkin]

@Barkin,

I actually prefer the more complicated test used by cimarron. The date function has to be executed to produce that new text, and a file created as a result. With the simple test you used I would worry that a mix-up in quoting gave me a false assurance that a vulnerable system was safe.

[michaellowe]

Hello everyone, firstly thankyou to @cimarron and @Geoffrey for your help, very much appreciated! I thought the least I could do was let everyone know who was concerned or for anyone reading this in the near future that the patch described in the subject of this post seems to have passed the test and the

"no such file or directory"

response was returned in the terminal as opposed to the date etc. so I am very happy with the result. apart from that yes I agree the media can get a bit hyped when it comes to such things, probably because half the idiots have big mouths with very small brains and don't actually understand what is at stake. please see screen shot for noobs sake.

[michaellowe]

@Kester,

You can also save yourself some tricky typing by simply highlighting the test command in your browser, directly from this web page, and then doing a "middle-click" in your console window. This will copy highlighted text without needing a cut-and-paste.

who would have thought??!!! Thank you Prehistoric for suggesting this. Now don't get me wrong I like typing and I'm keyboardcentric so I love hotkeys and keyboard shortcuts etc. but sometimes when executing complicated scripts like the bash up to date test comes one is pressed for time this neat little trick that you have shared with us mere mortal noobs is so appreciated. do you know how long I trawled the internet for this? google was useless! this did not come close in the search! so I thank you again for sharing the knowledge! brilliant! I got the impression from one forum that if you are running a gnome desktop the copy and paste function does not work in the terminal and I tried it many moons ago, it doesn't.
saving time is always appreciated, thanks!

[michaellowe]

I have considered removing Puppy Precise 5.7.1 from my dual boot (XP Pro) system by booting up my XP installation disc, opening the 'Repair' option and running 'fixmbr'. I would then return to using live discs for Puppy but perhaps there is no need to take such a drastic step - it's a question of lack of confidence caused by a lack of knowledge on my part. I'm more confident with Windows XP because I know it better but like Puppy very much and decided on dual booting for security reasons when Microsoft support for XP finished - I though I use Puppy for the bulk of my internet activity, so this Bash issue is a little ironic.

@Kester you could simply run as Spot whenever you want to browse the internet and then su privileges are removed making you less vulnerable if you were still worried about web pages being served from insecure webservers.

Please any of you puppy masters feel free to correct me if I am wrong.

[James C]

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

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

I just updated an old Mepis 11 install...... based on Debian Squeeze. Results>

Code: Select all

james@mepis1:~$ cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
date
cat: /tmp/echo: No such file or directory