Bitcoins at risk from BASH security vulnerability as dangerous as Heartbleed bug

[vanobe]

A new Linux GNU Bash security vulnerability is as serious as the Heartbleed bug for bitcoin.

https://www.cryptocoinsnews.com/bitcoin-at-risk-major-vulnerability-discovered-in-gnu-bash/

This security vulnerability affects GNU Bash versions 1.14 (released in 1994) through to the most recent version 4.3, according to NVD. The pervasive use of bash on systems across the internet means that the vulnerability is as serious as the Heartbleed bug. If you run a Linux (or any *nix) system it is most definitely vulnerable – and has been since it’s first boot.

[franky1]

its NOT a vulnerability for bitcoin directly. it is a vulnerability that people can hack linux systems..
its NOT saying that bitcoin-core is broke.

the OP is over hyping it... its almost like the OP is saying bitcoin is broke due to windows being hackable.

let me make it clear BITCOIN itself  is not vulnerable!! only users COMPUTERS are vulnerable if they are linux users that have their operating system is defaulted to use Bash as the system shell.

again bitcoin is not broken, but ANY computer data on your computer, whether its word documents, porn, photos email can be accessed remotely if your default linux shell is BASH, which by implication means people 'could' find your wallets.

im thinking this might be how the hackers got hold of celebrity photos on the apple cloud

[blatchcorn]

More FUD in attempts of driving traffic to blogs 

[vanobe]

I'm NOT saying bitcoin is hackable, I'm just trying to let people know about a BASH vulnerability that's as serious as the heartbleed bug to it. Anyone using Linux needs to upgrade now in addition to any exchanges using Linux.

The block of italic text in the OP is a quote directly from the linked article, and I agree with what it says. The pervasive use of bash on systems across the internet means that the vulnerability is as serious as the Heartbleed bug.

Please do not accuse me of spreading FUD, unless you think this BASH vulnerability endangers nobody's bitcoins.

[phillipsjk]

It is not as bad as heartbleed because the heartbleed bug would leave no logs.

Also, for the attack to work, the attacker has to rely on unsanitized inputs being passed to the shell. I don't think bitcoind does this.

I would have to check if my bitcoin node is actually using Bash. I know Bitcoind does not have root access.

[Remember remember the 5th of November]

Doesn't Bitcoin use the shell to execute wallet notify scripts?

[franky1]

Doesn't Bitcoin use the shell to execute wallet notify scripts?

if your running linux. then simply upgrade the bash shell. its a linux vulnerability not a bitcoin-core vulnerability. id say that banks, ATM's and government networks are more at risk, rather than every day users computers.

but i do laugh when people try to attach a operating system vulnerability to then specifically point it as if to sound like a blockchain / bitcoin brake.

[btchris]

Doesn't Bitcoin use the shell to execute wallet notify scripts?

Yes, and in some distros bash is the default /bin/sh shell (but not all, e.g. recent Debians / Ubuntus uses dash).

In order to be vulnerable, an attacker must:

(a) convince a process to set an environment variable to a value of the attacker's choosing, and then
(b) convince either that same process to spawn a copy of bash, or convince a child process to do so.

I don't think there's any way to convince Bitcoin Core to do (a), so it seems unlikely that Bitcoin Core could be an attack vector for this (but I'm not positive).

[ArticMine]

First of all this is a valid exploit and can be easily patched on GNU/Linux distributions by updating bash to the latest version. From https://www.reddit.com/r/Bitcoin/comments/2heu88/if_you_are_storing_bitcoins_on_a_linuxmac_system/

For example on Ubuntu 14.04 (GNU/Linux)

Code:

sudo apt-get update

sudo apt-get install --only-upgrade bash

The man page for bash on Ubuntu 14.04 (GNU/Linux) before the update on shows the following:
Bash is Copyright (C) 1989-2013 by the Free Software Foundation, Inc. This is fairly normal since it takes some time for packages to work their way into the final release of a GNU/Linux distribution.

Now when it comes to OSX this gets really interesting. From further down in the same reddit thread

OSX 10.8.5

So what now Update !

$ bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin12)
Copyright (C) 2007 Free Software Foundation, Inc.
$ env x='() { :;}; echo Vulnerable' bash -c "echo This is a test"
Vulnerable
This is a test

Background

http://www.theregister.co.uk/2014/09/25/shell_shocked_not_yet/

Solution

http://vigodome.com/blog/2011/12/30/change-default-shell/

Install Homebrew, then bash ...

The thread then goes to propose a fix by replacing the bash shell provided by Apple with a Homebrew solution and I would refer those interested in patching the OSX system to the reddit thread as a possible solution.

What I find very interesting here is the copyright notice, both regarding the date and the copyright holder. This brings up the following question. Why on earth would Apple be using a 7 year old version of bash? The answer is not technical but legal, and it relates to DRM. The critical change here is that the Free Software Foundation released the GPLv3 in 2007 and then began slowly porting packages to GPLv3. Here is one of many summaries on the subject. http://oss-watch.ac.uk/resources/gplv3. Suffice to say that implementing GPLv3, unlike GPLv2, deep in an operating system, such as in the case of bash, makes the whole operating system highly toxic to DRM. For those of us who value our freedom and liberty this is of course a very valuable feature; however if one wishes to create a modern version of the telescreen in George Orwell's 1984 or some thing close to it, using DRM, the presence of GPLv3 code deep in the OS is a fatal bug.

Apple was presented with a choice. Introduce GPLv3 code into OSX and IOS, thereby making these operating systems toxic to DRM or put its users at risk by using 7 year old FSF code that was still licensed under GPLv2. Apple decided to place the greed of organizations such as the MPAA and its own greed, by supporting DRM, ahead the legitimate security needs of its users when choosing to use 7 year old FSF code. The really disturbing question here is: What other vulnerabilities exist in OSX and IOS because of this reason?

At least Microsoft writes it own code to implement DRM, rather than use 7 year old code whose copyright belongs to an organization led by no other than Richard Stallman, https://en.wikipedia.org/wiki/Richard_Stallman! It may take an entrepreneurial class action litigation firm to heard enough of the iSheep into a class action lawsuit against Apple to actually secure OSX and IOS, by dealing with the underlying legal cause of these vulnerabilities.

[vanobe]

Doesn't Bitcoin use the shell to execute wallet notify scripts?

Yes, and in some distros bash is the default /bin/sh shell (but not all, e.g. recent Debians / Ubuntus uses dash).

In order to be vulnerable, an attacker must:

(a) convince a process to set an environment variable to a value of the attacker's choosing, and then
(b) convince either that same process to spawn a copy of bash, or convince a child process to do so.

I don't think there's any way to convince Bitcoin Core to do (a), so it seems unlikely that Bitcoin Core could be an attack vector for this (but I'm not positive).

The article linked to below says this is not a Bitcoin Core vulnerability. However, Bitcoin Core is stopped and started via the bash shell and can also be interacted with, via the bash shell

https://www.cryptocoinsnews.com/bitcoin-at-risk-major-vulnerability-discovered-in-gnu-bash/

It's desription of the DHCP attack vector is copied below, although it describes a number of other attack vectors which hit pretty specific server-type scenarios. Or running crafted bash scripts.

The exception is the DHCP attack vector. I’ll explain: What this actually does is the following: There is a protocol called DHCP – it gives the devices in your network an IP address. Normally, this is the router/server in your LAN.

Some guy could be running a 2nd DHCP server in a public LAN that gives out non-valid addresses or even a non-valid one. Because DHCP is a broadcast, your client will talk to this rogue server when he is the fastest to reply. So you would not even notice, but can still use the internet fine because after DHCP is done, the DHCP server is no longer needed for internet/network to function.

He could include a variable (mostly used to deploy Proxy settings etc). with a rogue string included, that string can be executed because Bash is broken – hence he could:

- Copy the wallet.dat over
– If DHCP client runs as root (some distro’s): Infect the machine with a keylogger/virus/rootkit
– etc.

Red Hat security advisory

https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/

NIST national vulnerability database

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

[btchris]

vanobe,

I (for one) appreciate your interest in this, and I agree it could theoretically lead to a wallet theft, but it would do wonders for your reputation if you didn't reference articles that are

• full of alarmist FUD,
• technically inaccurate in some aspects (e.g. the claim that PHP is completely invulnerable),
• not a respected source of security information,
• full of advertisements.

For example, the Red Hat security blog would have been a much better choice. (edited to add: oops, which I see you did include, silly me)

[vanobe]

I agree cryptocoinsnews has too many adverts, but at least it is not full of pop up boxes saying you have won a new laptop every 10 sconds. 

[MineForeman.com]

A quick test to see if you're valuable is to login and do this;-

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see;-

Code:

vulnerable
this is a test

You need to do something about it.  For it actually to be exploited by anyone requires a few other other things to be true about the system (webserver running an old style cgi script for example) but it should not be taken lightly.

I have a number of systems that I am patching that are vulnerable at the command line, none of them could be exploited to my knowledge at the moment but it is important none the less.

Neil

[Remember remember the 5th of November]

A quick test to see if you're valuable is to login and do this;-

Code:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you see;-

Code:

vulnerable
this is a test

You need to do something about it.  For it actually to be exploited by anyone requires a few other other things to be true about the system (webserver running an old style cgi script for example) but it should not be taken lightly.

I have a number of systems that I am patching that are vulnerable at the command line, none of them could be exploited to my knowledge at the moment but it is important none the less.

Neil

There is another article on the matter that even the patched version is still vulnerable, as the patch is incomplete.

[awesome31312]

More FUD in attempts of driving traffic to blogs 

Hey, don't mock. He really needs those eighty satoshis.

[ArticMine]

Here is the link from the US Department of Homeland Security on the subject. https://www.us-cert.gov/ncas/current-activity/2014/09/24/Bourne-Again-Shell-Bash-Remote-Code-Execution-Vulnerability I find it very significant that while it indicates the updates and patches to deal with this issue by major GNU/Linux distributions such as CentOS, Debian, Redhat and Ubuntu there is no mention of any action taken by Apple to address this issue on Mac OS X or IOS as of the time of this post.

Edit: Here is also the thread from the Free Software Foundation on the issue: https://lists.gnu.org/archive/html/bug-bash/2014-09/threads.html

[awesome31312]

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

Definitely an NSA attack

[ArticMine]

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

Definitely an NSA attack

The real threats here are for example organizations such as the NFL (National Football League) and other paddlers of "premium" content, not the NSA. DRM is the prime suspect as to why Apple is using 7 year old software.

Edit: Here is a post where apparently the FSF is saving Apple's skin on the DRM issue.

fluchtpunkt
21 hours ago at 02:06 am

No, as far as I have seen so far the first initial patch didn't actually fix the problem. The fact is that the bug was publicly disclosed yesterday, and you are ranting because there is no patch today, as of yet.

The bug is fixed. The patch is available. Apple could have rolled it out by now.

The GNU people even were so nice to backport the fixes to the ancient version Apple is using because Apple doesn't want code that's licensed with GPL v3.

http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-052

Apple just has to apply the patch and provide a new bash binary through software update. Apple does not have to identify the bug, they don't have to come up with a solution, they don't have to verify the fix. Everything is done already.

Stupid politics are the only thing that prevent the release of this bugfix. Probably because they like to bundle patches so people think their software is more secure because it isn't patched that often.

http://www.macrumors.com/2014/09/25/bash-flaw-os-x/