BASH exposure expressed as bigger than Heartbleed<SOLUTIONS>

[James C]

https://www.us-cert.gov/ncas/alerts/TA14-268A

Alert (TA14-268A)
GNU Bourne Again Shell (Bash) ‘Shellshock’ Vulnerability (CVE-2014-6271, CVE-2014-7169)

Systems Affected
GNU Bash through 4.3.
Linux, BSD, and UNIX distributions including but not limited to:
CentOS 5 through 7
Debian
Mac OS X
Red Hat Enterprise Linux 4 through 7
Ubuntu (link is external) 10.04 LTS, 12.04 LTS, and 14.04 LTS
Overview
A critical vulnerability has been reported in the GNU Bourne Again Shell (Bash), the common command-line shell used in most Linux/UNIX operating systems and Apple’s Mac OS X. The flaw could allow an attacker to remotely execute shell commands by attaching malicious code in environment variables used by the operating system [1] (link is external). The United States Department of Homeland Security (DHS) is releasing this Technical Alert to provide further information about the GNU Bash vulnerability.

[boof]

I have bash 4.4.1-can I conclude all ok?

[James C]

Free Software Foundation statement on the GNU Bash "shellshock" vulnerability

https://fsf.org/news/free-software-foun ... nerability

A major security vulnerability has been discovered in the free software shell GNU Bash. The most serious issues have already been fixed, and a complete fix is well underway. GNU/Linux distributions are working quickly to release updated packages for their users. All Bash users should upgrade immediately, and audit the list of remote network services running on their systems.
Bash is the GNU Project's shell; it is part of the suite of software that makes up the GNU operating system. The GNU programs plus the kernel Linux form a commonly used complete free software operating system, called GNU/Linux. The bug, which is being referred to as "shellshock," can allow, in some circumstances, attackers to remotely access and control systems using Bash (and programs that call Bash) as an attack vector, regardless of what kernel they are running. The bug probably affects many GNU/Linux users, along with those using Bash on proprietary operating systems like Apple's OS X and Microsoft Windows. Additional technical details about the issue can be found at CVE-2014-6271 and CVE-2014-7169.

GNU Bash has been widely adopted because it is a free (as in freedom), reliable, and featureful shell. This popularity means the serious bug that was published yesterday is just as widespread. Fortunately, GNU Bash's license, the GNU General Public License version 3, has facilitated a rapid response. It allowed Red Hat to develop and share patches in conjunction with Bash upstream developers efforts to fix the bug, which anyone can download and apply themselves. Everyone using Bash has the freedom to download, inspect, and modify the code -- unlike with Microsoft, Apple, or other proprietary software.

Software freedom is a precondition for secure computing; it guarantees everyone the ability to examine the code to detect vulnerabilities, and to create new and safe versions if a vulnerability is discovered. Your software freedom does not guarantee bug-free code, and neither does proprietary software: bugs happen no matter how the software is licensed. But when a bug is discovered in free software, everyone has the permission, rights, and source code to expose and fix the problem. That fix can then be immediately freely distributed to everyone who needs it. Thus, these freedoms are crucial for ethical, secure computing.

[Bushbuck]

[Edit 26/09 to remove questions]
Installing bash 4.2.048 update from the patches repo worked when I tried again today; thanks all for the helpful thread.

[gcmartin]

On a comment from a forum member, DASH may not have this vulnerability. Wondering about its compatibility.

• Can DASH replace BASH by removing BASH and setting a link to DASH along with PATH changes?
• Is that reasonable or inviting problems?

One other note:
This problem may also exist in embedded systems which use BASH....like your routers, etc. It could explain how some system/networks were breached assuming there are hackers who knew of this area of exposure.

[OscarTalks]

In any case there are updates available for all major distros so ubuntu, debian and slackware-based puppies are covered.

For T2 puppies (2.x, 4.x, wary, racy) the source code should be patched and recompiled to a new pet.

I took a look at Racy 5.5 and it has bash-3.0.16
I downloaded the source code of the same version and the corresponding version of the patch. I am not very experienced in applying patches to source code with patch but I think I figured it out. There does seem to be one path amendment that I had to make in the patch file but I am not sure about that. Anyway it all seemed to work and the version number updates to bash-3.0.17 and it passes the vulnerability test.

[mavrothal]

For those with wary/racy here is bash 3.0.20 compiled from BK's source and the gnu patches bash30-017, bash30-018, bash30-019and bash30-020, in Racy 5.5 with

Code: Select all

./configure --prefix=/usr --bindir=/bin --build=i486-pc-linux-gnu --with-curses  ac_cv_func_working_mktime=yes

[michaellowe]

hi everyone just heard about this on BBC radio 2 funnily enough. inm very concerned as I don't and never have known much about how to set up my firewall correctly. when I have a bit more time this evening I will post a fully detailed report with screen shots if necessary about how my machine is configured, correct kernel version etc. in the mean time is there anything immediate I can do to help fix or at least decrease my vulnerability to attack, on the radio they mentioned setting router to disable remote login or remote access. I have dynamic DNS anyway so have never used remote access. however have not actually checked to see whether it's enabled or not, would it be recommended to disable this setting, or any other pointers would be massively appreciated. can't afford a new machine, hence using precise on an old P4.

[prehistoric]

The whole idea of returning values in shell scripts by altering environment variables resembles the known bad practice of using global variables all over the place in ordinary programs.

I'm also wondering why programs which might interpret commands from sources on the Internet are launched by shells which have full scripting capabilities in the first place. A weaker shell like ash should be sufficient. This is what I would expect to find in embedded devices like routers.

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.? This could also save you from further exploits made possible by means not yet found. Using the full flexibility of bash simply to call untrusted programs was overkill to begin with.

[mavrothal]

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.

[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.