25 comments on “Bash “Shellshock” vulnerability – what you need to know”

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?

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.

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”.

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.

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 😦

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.)

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 🙂

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