Shellshock - a BASH vulnerability - *nix, MacOS, Android

[peterb]

I am posting this in GD because the effect of this has far reaching ramifications (unless you are a Windows user - in which case you can move on. )

BASH is a shell program that is a fundamental part of *nix operating systems. It actually stands for "Bourne Again SHell) and has been around for some 25 years. It appears that a vulnerability exits, introduced in version 1.3, that allows code injection, ie malicious code that can compromise the computer.

This affects Linux and MacOS machines, but because Linux is used in many embedded systems, it may affect them too. There is also the possibility that it could affect Android devices, particularly if they have been rooted, although there is no definite conformation that this is the case.

There are patches being developed, and the general advice is that patches should be applied as`soon as possible, particularly if you are running an internet connected server.

My own opinion (fwiw) is that it is cause for concern, but not panic! Firstly, the vulnerability has only just been announced, and there is no evidence to suggest that it has been exploited. (That doesn't mean it hasn't, of course) but now it is known about, I suspect that there will be hackers writing code to exploit it. Of course, the vulnerability can only be exploited if the code can be entered into the device, so normal physical and common sense security precautions apply.

Secondly, one method of getting the code in would be to run a web site purporting to have the "fix" whereas it is just a social engineering ruse to get exploitable code into a device. So be circumspect where you download any patches from.

For many this will be teaching you to suck eggs, but the potential consequences are too serious to let it pass uncommented.

More information here:

https://www.cert.gov.uk/resources/al...ka-shellshock/

http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

You only have to Google Shellshock to find a whole page of reports, ranging from the considered through to the alarmist/sensational. The two I have quoted are - IMHO - probably among the more authoritative.

[MrRockliffe]

I have 2 computers with Mac on them and an android phone - thanks for the heads up. Having said that no broadband anyway so doesn't make a difference. I only use my phone for messaging, music and of course hexus

[TheAnimus]

There was some info on an HN posting, that showed it been actively exploited in the wild against Apache and nginx. Someone had a proof of concept for drive by in Safari.

The level of severity of this bug is massive. Any application that has used an environment variable (that is many, many applications) can be exploited to some degree if this is used for anything that can be input, such as HTTP headers.

This could well be far worse than heartblead. All our effectable systems have been shut down / fully firewalled from public networks. Our front end guy who uses OSX has been forbidden from doing so until resolved. This is by far the most serious threat I've ever seen, because it affects so many applications, it isn't a case of firewall port x, or shutdown/patch app y.

[peterb]

There was some info on an HN posting, that showed it been actively exploited in the wild against Apache and nginx. Someone had a proof of concept for drive by in Safari.

The level of severity of this bug is massive. Any application that has used an environment variable (that is many, many applications) can be exploited to some degree if this is used for anything that can be input, such as HTTP headers.

This could well be far worse than heartblead. All our effectable systems have been shut down / fully firewalled from public networks. Our front end guy who uses OSX has been forbidden from doing so until resolved. This is by far the most serious threat I've ever seen, because it affects so many applications, it isn't a case of firewall port x, or shutdown/patch app y.

Yes, some interesting info here:

http://www.troyhunt.com/2014/09/ever...now-about.html

Just shut down my webserver overnight while I review the security set up (and closed the open port on the router). I do chroot apache once started, and the cgi-bin directory is write protected for non-root users.

[TheAnimus]

It's interesting to see the reaction to this. I think it's the most significant milestone in online security since Blaster if I'm honest, this is based mostly on the reaction of people I know in the industry.

The fun thing is, we have no idea what is compromised, without extensive analysis on each product. Whilst myself I've seldom used process environment variables as a data exchange mechanism, it's evidently common practice in the unix world, used almost as a poor mans data injection.

I've had to do risk analysis on our production networking kit ffs. We don't host the SSL endpoint thankfully on the router otherwise apparently we could have been compromised, which is nice.

As is the only ports open are http/https (HTTP telling you to piss off to HTTPS) and a VPN on non-standard port. Thankfully windows isn't effected by this. It's a great example of how our customers data, could be compromised. Whilst I probably take this too seriously and am a little bit paranoid, it's my job!

[directhex]

I am posting this in GD because the effect of this has far reaching ramifications (unless you are a Windows user - in which case you can move on. )

BASH is a shell program that is a fundamental part of *nix operating systems. It actually stands for "Bourne Again SHell) and has been around for some 25 years. It appears that a vulnerability exits, introduced in version 1.3, that allows code injection, ie malicious code that can compromise the computer.

This affects Linux and MacOS machines, but because Linux is used in many embedded systems, it may affect them too. There is also the possibility that it could affect Android devices, particularly if they have been rooted, although there is no definite conformation that this is the case.

There are patches being developed, and the general advice is that patches should be applied as`soon as possible, particularly if you are running an internet connected server.

My own opinion (fwiw) is that it is cause for concern, but not panic! Firstly, the vulnerability has only just been announced, and there is no evidence to suggest that it has been exploited. (That doesn't mean it hasn't, of course) but now it is known about, I suspect that there will be hackers writing code to exploit it. Of course, the vulnerability can only be exploited if the code can be entered into the device, so normal physical and common sense security precautions apply.

Secondly, one method of getting the code in would be to run a web site purporting to have the "fix" whereas it is just a social engineering ruse to get exploitable code into a device. So be circumspect where you download any patches from.

For many this will be teaching you to suck eggs, but the potential consequences are too serious to let it pass uncommented.

More information here:

https://www.cert.gov.uk/resources/al...ka-shellshock/

http://web.nvd.nist.gov/view/vuln/de...=CVE-2014-6271

You only have to Google Shellshock to find a whole page of reports, ranging from the considered through to the alarmist/sensational. The two I have quoted are - IMHO - probably among the more authoritative.

It shouldn't apply for embedded systems.

Embedded Linux ditches the GNU software stack (which includes the bash shell) for a minimal-disk-use alternative called Busybox. The Busybox shell, ash, should not be vulnerable.

directhex@RT-AC68U:/tmp/home/root# bash
-sh: bash: not found
directhex@RT-AC68U:/tmp/home/root# sh --help
BusyBox v1.17.4 (2014-07-15 17:23:32 CST) multi-call binary.

No help available.

[Lowe]

Mac OSX 10.9.5 seems to address this. I've got machines running 10.9.4 and they show up as vulnerable.

[TheAnimus]

We exploited this on our front end guys MBP running 10.9.5, so no, it's very vulnerable, very concerning, I wouldn't browse the web on it, or do anything on it outside of a safe sandbox.

[Lowe]

Hmm, odd. Using the code provided in the OP links it doesn't work under 10.9.5.

[Bagnaj97]

There was a patch for bash which appeared to fix it, but it was discovered to be an incomplete fix. The new CVE is CVE-2014-7169. Here's the updated test:

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable"

On a fully updated Debian Wheezy system everything appears fine, on Jessie however I'm still seeing:

adam@jessie:~# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable"
bash: X: line 1: syntax error near unexpected token `='
bash: X: line 1: `'
bash: error importing function definition for `X'
still vulnerable

So if you're running Debian Testing be careful!

On a patched bash (in this case under Wheezy) you should see:

adam@wheezy:~# env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable\!"
echo vuln
cat: echo: No such file or directory

[Lowe]

Ah, the updated test on 10.9.5 shows the same as you listed above. Arse.

[peterb]

Right - now fixed my version of Fedora Core 17 - downloaded the source for bash 4.3, applied the patches and recompiled - it did need a reboot.

The instructions I followed are here

John Vincent
Posted September 26, 2014 at 10:48 AM
You can recompile “bash” from source if you can’t find a precompiled version.

Log in as root, then run the following commands:

mkdir src
cd src
wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
for i in $(seq -f “%03g” 0 25); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
tar zxvf bash-4.3.tar.gz
cd bash-4.3
for i in $(seq -f “%03g” 0 25); do patch -p0 < ../bash43-$i; done
./configure
make
make install

The first line creates a directory called “src” and the next line makes that the current directory.
Then you run the “wget” command to get the “bash” source code.
Then you run a “for” loop to get each patch to the source code to bring it up to date, this includes the patch to fix the “shellshock” bug.
Then you run the “tar” command to extract the “bash” source code into a directory called “bash-4.3”, and then the next line makes that your current directory.
Then you run a “for” loop to apply each patch to the source code.
Then you run the “./configure” command to prepare the source code for compiling on your machine.
The you run the “make” command to compile the source code.
Finally you run “make install” to install your new version of bash.

I hope this helps…

from this site
http://fedoramagazine.org/shellshock...169-available/

There are a couple of errors in the instructions - you don't need the " " round %03g in the iteration loops, and there are now 27 patches, not 25. WARNING - do this at your own risk - there is always the possibility that you may break something else!

You will need the gcc compiler installed on your system, along with any dependencies that may require. If you have FC 19 or later, you will be able to update normally using YUM. Other distributions may have patched binaries available too, but if not, you may be able to compile from source - at your own risk.


Edit:

Moved to software

[peterb]

Apple users can update their version of bash here: http://support.apple.com/kb/DL1769

[Lowe]

Cheers - just updating all our machines.

[TheAnimus]

Apple users can update their version of bash here: http://support.apple.com/kb/DL1769

I'm actually pleasantly surprised that Apple got their act together to issue this patch within a week.

[peterb]

I'm actually pleasantly surprised that Apple got their act together to issue this patch within a week.

And a lot easier than updating my admittedly unsupported FC 17!

But given the scale of the problem, it isn't surprising, although I was surprised that it wasn't published as a system update through the Apple store route.