💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2014 › shocked_by… captured on 2023-04-26 at 14:26:59. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from September 2014. The article has been slightly improved.
The title of this post really suggested itself. I'm not writing about _shell shock's_ technical details however; 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_ shell, while widely available and convenient to use, is in fact fat, slow and ugly. Two weeks ago I began 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 the effort?) and the usual lack of time soon led 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.
Back in the days when Linux was "just a hobby" for me, I began to follow the big events 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. By adding even more operating systems to the mix, 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.
In case of the OpenSSL bug there were a lot of systems which didn't contain the vulnerability. Many distributions shipped older OpenSSL versions which weren't affected. This time things are far worse: Just about any single Linux server has the bash shell installed - and the vulnerability 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 _tcsh_ and OpenBSD comes with _ksh_ in the base system. Still bash is a dependency for some packages, so chances are that some version of bash is installed on many BSD systems as well.
As one would expect, the distributions are reacting to the problem in different ways and at different paces. When I turned on my computer at work and did the usual update, I noticed that 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 version of bash that was still 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...
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 a bit of 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 shell 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 mockery 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_ take a closer 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. Sure, 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!
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.