Sophos Cloud Optix
What is “Shellshock”?
Shellshock is the media-friendly name for a security bug found in Bash, a command shell program commonly used on Linux and UNIX systems.
The bug is what’s known as a Remote Code Execution vulnerability, or RCE.
This means that someone who isn’t already logged on to your computer might be able to trick Bash into running a program that it wasn’t supposed to.
Officially, the bug is documented as CVE-2014-6271 and CVE-2014-7169.
What’s a command shell?
A command shell is a program that helps you run other programs on Linux and UNIX, much like the Command Prompt on Windows.
Bash stands for “Bourne Again Shell” (a pun celebrating that it was derived from an earlier shell written by Stephen Bourne of Bell Labs).
You can use Bash interactively, typing in commands and immediately viewing the output, or as a tool to help you run a series of programs specified in a text file called a shell script.
If Bash is meant to help you execute code, how can it have a “code execution” bug?
A code execution bug in a program that is supposed to run commands for you does indeed sound like a contradiction.
But Shellshock exists because it is possible to trick Bash into running a program when you wouldn’t expect it to.
That may allow a remote attacker to send you text that you hand over to a Bash script as harmless looking data, only to find that it gets processed as if it were code, or program commands.
This sort of trickery is often known as command injection, because it involves sneaking in operating system commands, hoping that they get run by mistake.
Doesn’t server software take care with the data it feeds to Bash?
Server software that passes user-supplied data to Bash (and other installed programs) is usually very careful to watch out for known tricks.
For example, a Bash command line that contains a semi-colon is actually treated by Bash as if if were two separate commands.
So the Bash command:
echo Be careful; rm removes files
looks as though it ought to echo (i.e. print on the screen) the text Be careful; rm removes files.
But the semi-colon effectively turns it into two commands in sequence, first echo and then rm, which is the UNIX command to remove, or delete, files.
So the single line above actually ends up doing this:
echo Be careful ← Echoes "Be careful" rm removes files ← Zaps the files "removes" and "files"
The semi-colon turns rm into a command in its own right, thus causing a command injection error.
For that reason, server software usually looks out for various characters and constructions that have special meanings to Bash.
Anything that looks dangerous is blocked, or altered to make it safe (known as sanitising in programming jargon).
How come “Shellshock” attacks aren’t blocked too?
The problem is that, unlike the semi-colon example above, no-one knew what to watch out for until this bug was found.
The Shellshock bug occurs in a part of Bash that allows you to define functions, which is what programmers call a sequence of commands that are saved up for later.
In theory, defining a function, even a dangerous or malicious one, is harmless provided that the function never actually gets used.
So an unexpected semi-colon in command data passed to Bash ought to raise suspicion, but unexpected function definitions ought not to matter.
Because of the Shellshock bug, however, Bash can be tricked into running commands specified in a function definition, instead of storing them up harmlessly and not using them.
How do we fix this?
Update the Bash program so that it processes function definitions more carefully, and doesn’t run commands it isn’t supposed to.
Is an update available?
A reliable and complete patch for Bash is not yet ready. [2014-09-25T10:00Z.]
A partial fix exists, but it doesn’t fully solve the problem yet.
What about Sophos appliances and products?
As far as we are aware, none of Sophos’s Linux or UNIX products use Bash in a way that would allow this vulnerability to be exploited with data supplied by an attacker from outside.
Briefly put, attackers would need access to a Bash command shell first before they could use the bug to get access to a command shell.
Nevertheless, we intend to update any Sophos-supplied versions of Bash once a reliable and complete patch is ready and tested.
What about Sophos servers and services?
As far as we are aware, none of our servers or services could have been exploited due to his bug.
This includes our internal business systems, Sophos web servers, update servers, partner portal and support forums.
For further information
For further information, please visit Sophos Knowledgebase Article 121444.
Images of cartoon bomb and oyster shell courtesy of Shutterstock.
Am I being over simplistic? Why not simply remove the bash executable from vulnerable Linux systems. Users can use the Bourne shell or C-shell while a fix is produced. Scripts should probably be using these instead of bash anyway?
That might work. It would certainly remove the bug temporarily 🙂
But you might find a lot of things break, especially if the distro itself includes, or users have installed, software that relies on Bash-specific scripts.
First of all, a lot of things depend on bash, and they would break. Other shells don’t have the same syntax, so unless scripts are very simple, they won’t run in the other shells.
But the more important problem is, you may have more Linux systems than you think you do. Many routers run Linux, for example. How are you going to log on and delete bash from those? Technically, your Android phone is a Linux system, too, but fortunately, things don’t usually run bash on it.
Quite a few SoHo routers use a simplified shell like “ash” from Busybox instead of bash, to save disk space and memory.
Of course, if you can’t get a shell on your router, you may not be able to tell 🙁
Linux system boot up scripts are full of references to the bash shell. You can remove it, if it isn’t currently running, but your server wouldn’t start up normally, if at all, after then next system reboot.
Glad this bug was discovered but the impact of it is being very dramatically reported without very much detailed information appearing in mainstream press other than it effects “Apple,Linux, and Android” is “worse than Heartbleed” and “early attacks are occurring”.
It’s a command shell: you still need to escalate privilege and access it in order to make use of this internet destroying “bug”.
AFAIK Android is not affected (it uses mksh in place of Bash, or BusyBox for rooted users who have chosen to install it).
Also, some guy made a PoC which unfortunately has already been modified to serve malicious code.
“Also, some guy made a PoC which unfortunately has already been modified to serve malicious code.”
What is a “PoC” in this context, please?
Proof of Concept
I just ran the diagnostic code on my Mac OS X 10.9.5 shell, and it came back “vulnerable”. There are no updates available for 10.9.5 — I hope Apple is working on a patch quickly.
From some other sites I understand that my vanilla OS X system is not vulnerable since I do not “configure advanced UNIX services.”
But, what about my wireless Linksys router? Can I expect eventually to find some information on their web site?
Does your router run Bash, or (more common) busybox? Cisco will probably be putting out a notice for current Linksys routers that are running the Bash shell, but I can’t see much of a reason for most commercially installed firmwares to contain Bash. If you’re using Tomato or some other custom router firmware, you may want to make sure you didn’t install Bash.
OK, I have a TP-Link home router, with DHCP and all that stuff on it. I don’t know if its code includes Bash or not.
1. Is there any way to find out?
2. If it has Bash, is it vulnerable to be exploited from the internet? Or does it need to be attacked from inside of the network to cause harm?
Depends on what services are listening on the outside interface – if you have web access from outside (not recommended!) then the web server probably uses shell scripts to run commands to do stuff…this could make you vulnerable. As to “do you have bash” – can be hard to say. Sorry 🙁
http://forum.tp-link.com/showthread.php?77552-Shell-shock-vulnerability
“the modem / router tp-link are not vulnerable because they do not use bash but busybox “
At my work we are doing a lot of work on this bug and the attack surface if pretty large. We have already found two incredibly simple ways any user with shell access can get root privileges. If you have any suid executables that call any bash scripts at all it is very likely you can get root privileges. It will even work if you call an suid executable that as part of the run calls another executable, that in turn calls a bash script.
Busybox is not susceptible so all home routers should be safe. I haven’t seen a router that uses bash yet.
I wouldn’t say “all.” Not because I’ve seen a SoHo router that uses Bash, but because there are *lots* of different routers out there, and variety is the spice of life, or something. (And see @Andrew Ludgate’s comment about Linksys routers with Bash.)
Serious, yes, but still a Storm in a teacup here, Folks,
While it is being sorted out, switch over to the “MKSH” (MirBSD) shell.
As it did not and does not use the GNU tool kit chain, it has not been built with the “readline” issue that exploits “Bash”.
However, like “Bash” the “MKSH” shell supports almost all of the same syntax and will run “Bash” scripts in a “SH” compatibility mode.
The Korn shell is also very old and very well tested.
I.E. HP, SUN, IBM, etc. all usually default to this command shell.
Unless you have something very “Bash” specific, MKSH” will do for now, if you are concerned.
Anything else that does not require “Bash” specifically should be swapped over.
Also please not that the “SH” command shell has the same problem as the “Bash” command shell.
I would also be looking at any script that uses the “readline” function or passes Unsanitized input or output to any “BASH” or “SH” shell.
One minor item, Google “Korn shell .profile and .kshrc” first, and make sure that you update or create the equivalent of the “.bash_profile” and “.bashrc” before you swap your shell over.
Also, you can pretty much cut and paste most of your “.bash_profile” into “.profile” and it will work.
For more advanced tricks, check out the “/etc/profile” script and the “/etc/profile.d/” directory, as applicable, to your platform.
Linux & Unix built in workarounds to issues since their inception.
Problem solved for now.
As we said, switching away from Bash _is_ a workaround (or solution, if you prefer), but there’s the little matter of satisfying yourself that you won’t break anything.
On a desktop computer, probably no big deal. On a revenue-generating web server farm, maybe a bit tricker. (The little phraselets in your comment such as “almost all of the same” and “you can pretty much cut and paste” might not be comforting enough for a sysadmin to take to the CTO 🙂
Lucky ksh users of OpenBSD. 🙂
Today is Monday, Sept. 29. I run the 64-bit MATE version of the current release of Linux Mint (Qiana.)
Overnight, there was an update to bash. It is Ubuntu code, so Ubuntu received the same update.
There may be other updates to follow (it seems that there’s been a sort of domino effect in bug finding here) so keep watching that space.
look up Shellshock becomes whack-a-mole
I appreciate the effort made in patch bash43-026, but this patch doesn’t even BEGIN to solve the underlying shellshock problem. This patch just continues the “whack-a-mole” job of fixing parsing errors that began with the first patch. Bash’s parser is certain have many many many other vulnerabilities; it was never designed to be security-relevant.
You are in a maze of twisty passageways, all alike.
>GO SOUTH
You are in a maze of twisty passageways, all alike.
>GO SOUTH
You are in a maze of twisty passageways, all alike.
>$({;})GO SOUTH
You are in a maze of twisty – passageways: command not found
Systems running qmail and an unpatched version of bash are vulnerable if any user has a .qmail utilizing program delivery/ e.g. procmail.