Bug in Bash shell creates big security hole on anything with *nix in it
Could allow attackers to execute code on Linux, Unix, and Mac OS X.

by Sean Gallagher - Sept 24 2014, 1:45pm PDT
ShareTweet
181

Mac OS X Mavericks is also a *nix, and also vulnerable to the Bash bug.
Sean Gallagher
A security vulnerability in the GNU Bourne Again Shell (Bash), the command-line shell used in many Linux and Unix operating systems, could leave systems running those operating systems open to exploitation by specially crafted attacks. “This issue is especially dangerous as there are many possible ways Bash can be called by an application,” a Red Hat security advisory warned.

The bug, discovered by Stephane Schazelas, is related to how Bash processes environmental variables passed by the operating system or by a program calling a Bash-based script. If Bash has been configured as the default system shell, it can be used by network–based attackers against servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Because of its wide distribution, the vulnerability could be as wide-ranging as the Heartbleed bug, though it may not be nearly as dangerous. The vulnerability affects versions 1.14 through 4.3 of GNU Bash. Patches have been issued by many of the major Linux distribution vendors for affected versions, including:

Red Hat Enterprise Linux (versions 4 through 7) and the Fedora distribution CentOS (versions 5 through 7)
Ubuntu 10.04 LTS, 12.04 LTS, and 14.04 LTS
Debian
A test on Mac OS X 10.9.4 ("Mavericks") by Ars showed that it also has a vulnerable version of Bash. Apple has not yet patched Bash, though it just issued an update to "command line tools."

While Bash is often thought of just as a local shell, it is also frequently used by Apache servers to execute CGI scripts for dynamic content (through mod_cgi and mod_cgid). A crafted web request targeting a vulnerable CGI application could launch code on the server. Similar attacks are possible via OpenSSH, which could allow even restricted secure shell sessions to bypass controls and execute code on the server. And a malicious DHCP server set up on a network or running as part of an “evil” wireless access point could execute code on some Linux systems using the Dynamic Host Configuration Protocol client (dhclient) when they connect.

There are other services that run on Linux and Unix systems, such as the CUPS printing system, that are similarly dependent on Bash that could be vulnerable.

There is an easy test to determine if a Linux or Unix system is vulnerable. To check your system, from a command line, type:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
If the system is vulnerable, the output will be:

vulnerable
this is a test
An unaffected (or patched) system will output:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
The fix is an update to a patched version of the Bash shell. To be safe, administrators should do a blanket update of their versions of Bash in any case.

-=-=-=-=-=-=-=-=-=-

(personal note)
I tested for this exploit on a Linux machine, a hackintosh, and my OpenBSD 5.4 machine. All had this vulnerability, by default. Except, of course, for the OpenBSD machine, where I'd installed bash manually via the ports collection in order to keep some luddite users happy.

Seems to be almost everywhere. I'd suggest trying to patch this up real quick.

---
� Synchronet � Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: Bash exploit in the wild
By: Khelair to All on Thu Sep 25 2014 07:50 am

Because of its wide distribution, the vulnerability could be as
wide-ranging as the Heartbleed bug, though it may not be nearly as dangerous. The vulnerability affects versions 1.14 through 4.3 of GNU Bash. Patches have been issued by many of the major Linux distribution vendors
for affected versions, including:

It is more dangerous. Heartbleed didn't allow remote code execution.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
� Synchronet � My Brand-New BBS (All the cool SysOps run STOCK!)

Hello Khelair,

On 25 Sep 14 07:50, Khelair wrote to All:

Seems to be almost everywhere. I'd suggest trying to patch this up
real quick.

Thanks for the heads up! Fortunately, my Archlinux VM was updated yesterday and
must have come with that patch. I remember bash being upgraded, and I get the second (non-vulnerable) result when I type that command in.

My non-upgraded Gentoo box, on the other hand.. lol

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: Bash exploit in the wild
By: Access Denied to Khelair on Thu Sep 25 2014 04:52 pm

Subject: Re: Bash exploit in the wild

Thanks for the heads up! Fortunately, my Archlinux VM was updated yesterday and must have come with that patch. I remember bash being upgraded, and I get the second (non-vulnerable) result when I type that command in.

Heh, I noticed that too. I had seen the alert pretty much day 1 of it's report and noticed Arch was already patched, and quite amazed about how quickly they did it. Heck, they did it faster than CentOS/RHEL, which by itself is pretty dang quick.

---

[Psi-Jack -//- Decker]

� Synchronet � Decker's Heaven -//- bbs.deckersheaven.com

Re: Bash exploit in the wild
By: Khelair to All on Thu Sep 25 2014 07:50 am

Seems to be almost everywhere. I'd suggest trying to patch this up real
quick.

I wonder how many sites are running bash CGI scripts? I remember writing a few quick and dirty BASH scripts back in the day.

---
� Synchronet � realitycheckBBS -- http://realitycheckBBS.org

I wonder how many sites are running bash CGI scripts? I remember writing a few quick and dirty BASH scripts back in the day.

From what I understand it affects more than just bash scripts. For example a perl/php script doing `some_command` may be vulnerable as well if the some_command gets executed via bash.

---
� Synchronet � R&M Software Support BBS

Re: Re: Bash exploit in the wild
By: Ree to Poindexter Fortran on Fri Sep 26 2014 03:46 pm

I wonder how many sites are running bash CGI scripts? I remember writing a few quick and dirty BASH scripts back in the day.

From what I understand it affects more than just bash scripts. For example a perl/php script doing `some_command` may be vulnerable as well if the some_command gets executed via bash.

i'm not so sure it's as bad as heartbleed, though.
---
� Synchronet � ::: BBSES.info - free BBS services :::

Re: Re: Bash exploit in the wild
By: Psi-Jack to Access Denied on Fri Sep 26 2014 11:09 am

Heh, I noticed that too. I had seen the alert pretty much day 1 of it's report and noticed Arch was already patched, and quite amazed about how quickly they did it. Heck, they did it faster than CentOS/RHEL, which by itself is pretty dang quick.

The initial patch doesn't completely close the hole... just a heads-up.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
� Synchronet � My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: Bash exploit in the wild
By: Mro to Ree on Fri Sep 26 2014 04:01 pm

i'm not so sure it's as bad as heartbleed, though.

It's worse. Heartbleed was "only" information disclosure and only impacted one
version for a short period of time, so not many embedded devices had it, and those that did were still in active maintenance mode.

The bash bug is remote execution, and has existed for about 25 years. Many devices which include bash have been shipped and are well past their support date (think smart TVs, routers, DVD and Blu-Ray players, etc) and will never be
fixed by the manufacturer.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
� Synchronet � My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: Bash exploit in the wild
By: Deuce to Psi-Jack on Fri Sep 26 2014 04:59 pm

Re: Re: Bash exploit in the wild
By: Psi-Jack to Access Denied on Fri Sep 26 2014 11:09 am

Heh, I noticed that too. I had seen the alert pretty much day 1 of
it's report and noticed Arch was already patched, and quite amazed
about how quickly they did it. Heck, they did it faster than
CentOS/RHEL, which by itself is pretty dang quick.

The initial patch doesn't completely close the hole... just a heads-up.

Hmmm, what's missing in it, and got any resources on that?

---

[Psi-Jack -//- Decker]

� Synchronet � Decker's Heaven -//- bbs.deckersheaven.com

Re: Re: Bash exploit in the wild
By: Psi-Jack to Deuce on Sat Sep 27 2014 01:09 am

The initial patch doesn't completely close the hole... just a
heads-up.

Hmmm, what's missing in it, and got any resources on that?

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

Basically, carefully crafted invalid function declarations can trigger it as well.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
� Synchronet � My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Re: Bash exploit in the wild
By: Deuce to Psi-Jack on Sat Sep 27 2014 01:32 pm

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-4236

Sorry, that's the wrong link.

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

Is correct.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
� Synchronet � My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Bash exploit in the wild
By: Poindexter Fortran to Khelair on Fri Sep 26 2014 07:57:22

I wonder how many sites are running bash CGI scripts? I remember writing a few quick and dirty BASH scripts back in the day.

For sure. I remember the same. Heh. Suspecting something like this might happen at some point is pretty much the reason I changed all of my common usage shell scripting into stuff written strictly for /bin/sh, despite how much more lobotomized it normally is.

---
� Synchronet � Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: Re: Bash exploit in the wild
By: Ree to Poindexter Fortran on Fri Sep 26 2014 15:46:36

From what I understand it affects more than just bash scripts. For example a perl/php script doing `some_command` may be vulnerable as well if the some_command gets executed via bash.

Pretty sure you're right about that. I know there are particular apache modules that can be loaded that make it fully vulnerable to exploits in the same vein, as well. Not that apache is well renowned for being secure, or anything.

---
� Synchronet � Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Re: Re: Bash exploit in the wild
By: Deuce to Psi-Jack on Fri Sep 26 2014 16:59:20

The initial patch doesn't completely close the hole... just a heads-up.

What I've been wondering, and I'm addressing this to anybody, I guess, though I pointed it as a reply to you because I'm thinking you may well know better than a lot of others, is what the ':' in the script does? I mean, I know that it's integral to the vulnerability, but I can't place how the ':' is interpreted. Every other character I understand. My suspicion is that the ':' is interpreted as its usage as a tertiary operator, but that doesn't seem to totally add up, either. I'm trying to understand what the logic in the punctuation is so that I can understand where the security hole lies in bash, just to increase my general understanding, but I haven't found it laid out well anywhere, yet.

---
� Synchronet � Tinfoil Tetrahedron BBS telnet or ssh -p 2222 to tinfoil.synchro.net

Hello Psi-Jack,

On 26 Sep 14 11:09, Psi-Jack wrote to Access Denied:

Thanks for the heads up! Fortunately, my Archlinux VM was updated
yesterday and must have come with that patch. I remember bash
being upgraded, and I get the second (non-vulnerable) result when
I type that command in.

Heh, I noticed that too. I had seen the alert pretty much day 1 of
it's report and noticed Arch was already patched, and quite amazed
about how quickly they did it. Heck, they did it faster than
CentOS/RHEL, which by itself is pretty dang quick.

I think I actually remember the update being before I een heard th announcement
for the first time. Once I heard the annoucement, I was like "Hmm, I remember bash upgrading a few days ago" or some such. Either way, it was definitely nice
to see in one of the distros I use.

On the other hand, it looks like Gentoo just got the patch over this past weekend, which is a little upsetting. I hadn't upgraded my Gentoo machine in quite some time, and figured it was a good time to do so (Thursday).. only to find bash was not updated during that entire time.

We took off to go camping for the weekend, and now that we're back I checked if
there was an upgrade for bash in portage, and there finally was. I'm not quite sure what took them so long compared to others, but at least it's done now I suppose.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20130910
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (723:1/701)
� Synchronet � thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin)

Re: Re: Bash exploit in the wild
By: Mro to Ree on Fri Sep 26 2014 16:01:40

Avast, my dear pukes!

i'm not so sure it's as bad as heartbleed, though.

... The typical statement of someone who actually has no idea. Jokes.

art@fatcatsbbsdotcom

"My dishonor among Klingons may offend Ambassador K'Ehleyr."
"Lieutenant, you are a member of this crew and you will not go into hiding
whenever a Klingon vessel uncloaks."
"I withdraw my request, sir."
-- Worf and Picard in ST:TNG "Reunion"



---
� Synchronet � fatcats bbs - fatcatsbbs.com