BASH exposure expressed as bigger than Heartbleed<SOLUTIONS>

[Dingo]

I just patched the bash 4.3 sources against latest available patch ( but we need a further patch as far as I understand) and compiled for Puppy 3.01, but I'm not sure it is safe to replace the bash 3.00.16 built-in in Puppy 3.01 with bash 4

[bark_bark_bark]

Is there an updated version of bash for LxTahr 14.09 yet?

[dejan555]

EDIT: See this post for latest version(s)

[Jasper]

Hi dejan555,

Works with Precise 5.6, thank you.

My regards

[slavvo67]

Dejan's patch also works on OV Precise 5.8. Thanks Dejan!

[anikin]

For all Ubuntu based puppies (lucid, precise, raring, saucy, trusty, utopic) bash is available here:
http://packages.ubuntu.com/trusty/i386/bash/download
http://security.ubuntu.com/ubuntu/pool/ ... 1_i386.deb
This one is for trusty, select your release on the top of the page.

[Sky Aisling]

So help me, the non-geek, to understand if this effects me.

If I use a bash terminal will I be venerable to this bug?
For example: I often do a 'dmesg' command through the console.

jamesbond writes:

The vulnerability is *NOT* as big as Heartbleed, because most people don't use bash as a "server" Smile

[anikin]

Ubuntu and other Debian-derived systems that use Dash exclusively are not at risk – Dash isn't vulnerable, but busted versions of Bash may well be present on the systems anyway. It's essential you check the shell interpreters you're using, and any Bash packages you have installed, and patch if necessary

==>http://www.theregister.co.uk/2014/09/24 ... hell_vuln/

[slavvo67]

OK, so at least the patch is there, though maybe not the perfect fix. Now, does anyone know if the patch any negative effect on bash or its scripts?

[James C]

Some more info...

http://www.pcworld.com/article/2687857/ ... k.nl_today

When it gets down to brass tacks, most major websites and modern gadgets you own likely won't be affected by this Bash vulnerability, and Apple will no doubt patch the OS X implementation quickly. (Here's a highly technical DIY fix for now.)

It's impossible to know just how far this flaw reaches, and it's likely to linger on in neglected websites, older routers, and some legacy Internet of Things devices—many of which are impossible to patch—providing an opening for determined hackers to sneak into those systems.

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