Shocked by the shell

The title of this post really suggested itself. I’m not writing about shell shock’s technical details; people who care have surely read about it more than enough by now.

The funny thing is that I had in fact already decided to write this month’s blog post about shells before the shell shock happened! For quite a while I’ve been under the impression that the BASH, while widely available and convenient to use, is fat, slow and ugly. Two weeks ago I begun playing with a variant of the korn shell called mksh, and realized that I finally might have found the alternative shell that I had been looking for.

Laziness (learn to use a whole new shell properly? Is that really worth so much effort?) and the usual lack of time soon lead to myself being in two minds about the topic. But I guess that I just received the final bit of motivation… So I’ll likely write about it soon.


The “shell shock” BASH bug hit us all

Shocked!

Back in the days when Linux was “just a hobby”, I begun to follow the big incidents in the *nix world. “Just for fun” (and because it was interesting). Now that I work for a hosting provider it is more important for me to catch these things and react to them.

While most of our customers have no preference when it comes to the server OS, some do insist on a specific distribution. And since the company I work for bought a competitor some years ago, their infrastructure was taken over as well. Adding even more operating systems, that is the reason for our quite diverse server landscape. So before long I had the opportunity to learn the differences between FreeBSD, OpenBSD, Ubuntu, Debian, Gentoo, Fedora, CentOS, …

Doing the normal updates is something that takes quite a bit of time. But it is something way different if you have to do updates in a hurry. It was a lot of work when suddenly the infamous OpenSSL bug made our hearts bleed not even half a year ago. Now the second catastrophic bug hit us – and this one is even more off the scale than the previous one.


The “heartbleed” bug logo

Vulnerable? / Still vulnerable?

In case of the OpenSSL bug there were a lot of systems which didn’t have the hole. Many distributions shipped older OpenSSL versions which weren’t affected. This time things are far worse: Just about any single Linux server has a BASH shell – and the hole has existed for more than two decades…

The only exception is some embedded Linux systems which often use Busybox because it is much smaller and doesn’t need as many system resources as BASH does. That – and *BSD. The BSDs don’t use the BASH by default. FreeBSD uses the tcsh and OpenBSD comes with the ksh in the base system. Still BASH is a dependency for some packages, so chances are that some version of the BASH is installed on many BSD systems as well.

Like one would expect, the distributions are reacting to the problem in different ways and at different times. When I turned on my computer at work and did the usual update, I noticed that the BASH received an upgrade. A while later I read about shell shock and pasted the test line on my terminal emulator – receiving an error. Obviously Arch Linux had already closed that hole with the update. My colleagues, running different distributions on their workstations (we are allowed to choose the operating system and distribution ourselves) did updates as well. Most of them were left with a BASH that was vulnerable.

The next day, BASH received another update on my system. Soon I heard that the first “fix” didn’t close the hole completely. Again my system wasn’t affected anymore while more or less all servers that we had updated showed the string “still vulnerable! :(” using the latest test. So they had to be updated again – including the ones that had been problematic yesterday. Not fun to do…

Problem solved?

After a long day at work I updated my machines at home, too. On a FreeBSD system I noticed that they added a new config option to restore the old behavior without giving the –import-functions parameter. Well, perhaps some people really need it. At least it is a much better idea to disable that functionality by default than it is to mess with some prefixes for the functions…

This morning I found some time to look at the issue again. Seems like it’s not over, yet… A lot of people seem to be taking a closer look at the BASH right now – which is a good thing without any question. But the big mess has already happened and of course we’re target to the mock and scorn of the advocates of closed source software. While I don’t think that we deserve it (the BASH bug was communicated and fixed rather quickly after all and now people do look at the source code which they couldn’t if it wasn’t available), it will not exactly be very helpful in building and maintaining a good reputation.

So what is the real problem? IMHO it is that the idea of simplicity is traded for complexity far too often. Right, in some cases complex software is needed. But there’s no excuse to make things more complex than necessary. The idea to have as many features as possible in a single program is certainly not Unix!

Where do we go?

We currently live to see what looks like the victory of complexity. Systemd conquers all major distributions, DEs like GNOME are already beginning to count on it being present. Monsters like cmake are called “modern solutions” and spread like cancer. Proprietary blobs are ubiquitous. All these things won’t make life easier for us. They might do so at first sight. But on the long run we will continue to run into trouble.

Fortunately there are people who have understood the problems of over-complexity and try to react to it. I’ll write about this topic next time.