The folks that come up with these titles like heartbleed and then shellshock really should be in marketing.

I’m not going post on the what and why . There are many resources online that can be searched.

Let’s just say, that this is bad in lacking bounds checking.

cd /tmp; rm -f /tmp/hacked; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/hacked
date

The reality is that security is always taken lightly and put to the back seat for convenience. Bourne Again Shell in my humble opinion is not the issue, but the process to which it can be utilized.

Synology

Synology uses busybox; so it uses sh. However, sniffing through I come up with a hit for “bash” and it turns out it was for a package for heart beats communication between synology box’s.

A quick test yeilds:

env X="() { :;} ; echo HACKED" /usr/syno/synoha/bin/bash -c "This is a test"

"hacked"
 "This is a test"

Which is no surprise since  it’s using bash, but does the flaw extend outside of that service? At the moment I can’t find a way to execute that service through an external link (sorry, not smart enough yet).

Other system with bash in the environment this is the typical test:

env X="() { :;} ; HACKED"  -c "This is a test"

This only works if bash is in the environment for you to call up. It could be hidden in a package like with Synology or something popular like Optware.

Optware is popular in many firewall applications.

Fixed version you would see:

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

One last thing to check the version to see if you have the latest patch:

foo=’() { echo not patched; }’ bash -c foo

Before going on a mass panic and checking firewall devices and applications.  Keep in mind that you need a service that is exposed that would or can be called and makes use of the bash command.