13

Considering that RedHat and other major teams in business are conducting an audit in bash and have uncovered a few other vulnerabilities besides -7169 (-7186 and -7187), is it sensible to link /bin/sh to another shell?

Both -7186 and -7187 were found by one researcher - Florian Weimer - in just a few days (RedHat has been working on Shellshock since September 14), independently discovered by Todd Sabin from VMWare. Just how many more lurk there is anyone's guess. By the way, I'm not talking about permanent replacement, just suspension till things clear up.

Deer Hunter
  • 5,297
  • 5
  • 33
  • 50
  • I stopped using bash a while ago because it is a terrible shell. Try ZSH or fish, they are really helpful and easy to use. – rook Sep 27 '14 at 16:29
  • 5
    What shell you have as your default doesn't matter as one can execute a script using any shell on the system using the correct shebang line: `#!/bin/bash` - I am not aware of a way to prevent this short of removing bash from the system entirely. – cyberwombat Sep 28 '14 at 00:27

5 Answers5

19

To determine definitively the degree to which this might or might not be "a prudent step", I think you would have to do some original security research on the possible replacements, which include:

  • Debian's dash
  • OpenBSD's ksh
  • Busybox ash
  • MirBSD/MirOS mksh
  • ...and certainly others

Mark's answer suggests that at least OpenBSD's has received security scrutiny already, but I'm not sure of the extent or whether there's evidence to back this up (clearly, they did not apply any scrutiny to a cornerstone of comms security (OpenSSL) until recently when they forked it into LibreSSL). On the other hand, it's pretty clear to me that nobody had bothered to read the Bash source for security until recently, or "shellshock" would have been discovered a long time ago; the whole "function importing" thing is a huge red flag that any security researcher would scrutinize as soon as they saw it (and hopefully recommend the entire feature for removal). But for the others, it's not as clear.

What is clear, though, is that all of the above have a much smaller attack surface than Bash. In order for an attacker to take control over a program, there has to be some input channel. These can of course be non-obvious things like resource limits, system clock, etc. but they're still inputs; a program with absolutely no inputs is trivially non-vulnerable. The security design bug in Bash is that it's taking potentially untrusted inputs (the contents of arbitrary environment variables) and subjecting them to complicated processing (parsing as code). On the other hand, as far as I'm aware, none of the above-listed shells do any processing of the contents of environment variables (except individual ones with specified established meaning like LANG and LC_*, ENV, IFS, PATH, PS1, etc.) or other input; they just treat the contents as abstract data which is passed through.

So from a security design standpoint, even without auditing these alternatives, I would estimate them to be safer choices than Bash. Whether that will remain the case it not clear. Certainly Bash is getting a lot of new attention right now, which other shells are less likely to receive, so we could end up with most of the issues in Bash getting fixed while issues in other shells remain unknown. Then you have various factors to consider, like whether you're likely to targeted individually, in which case using less-mainstream software may be a liability.

Personally, I use Busybox ash most places. If nothing else, both ash and dash use about 1/5 the memory of bash and start 2-8 times faster, so they're very practical choices from a non-security standpoint as well.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
R.. GitHub STOP HELPING ICE
  • 7,813
  • 1
  • 23
  • 34
  • 2
    You second para seems to imply some major relation between OpenBSD and OpenSSL that I must take issue with. The OpenBSD project are not the ones behind OpenSSL (they are however, beyond the LibreSSL fork that came out of the Heartbleed fiasco). That bit of innuendo does not reflect well on this answer and simply smears on the OpenBSD team's stance on security. – muru Sep 27 '14 at 16:02
  • 1
    @muru: Sorry, that wasn't my intent. I just meant that there seems to be a perception (whether intended by the OpenBSD team or not) that everything in the core system has been vetted for security, whereas this doesn't actually seem to be the case. Also, while OpenSSL is not an OpenBSD product, it's a core dependency of OpenSSH, which is. – R.. GitHub STOP HELPING ICE Sep 27 '14 at 17:20
  • 2
    [No longer a core dependency](http://article.gmane.org/gmane.os.openbsd.cvs/130612), it seems. – muru Sep 27 '14 at 17:25
  • It is still a requirement for a useful ssh client or server that interoperates with anything but itself. Without OpenSSL, OpenSSH does not support any of the standard ciphers/key types, making it rather useless in a typical setup with RSA-based public key authentication. – R.. GitHub STOP HELPING ICE Sep 27 '14 at 17:27
  • @muru was that just making it so they could plug their LibreSSL fork in as an alternative? – Dan Is Fiddling By Firelight Sep 28 '14 at 01:36
11

The only shell I know of that's been seriously inspected for security issues is OpenBSD's variant of ksh, and I don't know if that can be installed on a Linux system. Other than that, the only security advantage from changing your system shell is that by using a less-common shell, fewer people will be targeting you -- but by the same token, fewer people will be looking for bugs in your chosen shell.

Debian/Ubuntu avoided most of the trouble because they had dash as their system shell, and the *WRT router distros did because they use busybox, but neither selected their shell for security reasons. In both cases, the alternate shell was selected to improve performance by reducing load times and memory footprint.

Mark
  • 34,390
  • 9
  • 85
  • 134
  • 3
    While I agree that other sh implementations have probably not been inspected as closely as OpenBSD's, they all have very minimal attack surface compared to bash. From a security design standpoint, the problem in bash was not the parser bug, but the whole concept of parsing contents of environment variables. Other shells generally do not have code paths that branch based on the content of environment variables except for a fixed set of variables that are meaningful to them. Any attack requires some kind of input channel, and non-bash shell implementations have a lot fewer input channels. – R.. GitHub STOP HELPING ICE Sep 27 '14 at 13:32
  • 2
    @R.. I urge you to write an answer with proper approaches to comparing the Shells. Much of this thread is based on speculation rather than reasoning... – Steve Dodier-Lazaro Sep 27 '14 at 14:02
  • @SteveDL: Done. – R.. GitHub STOP HELPING ICE Sep 27 '14 at 14:26
8

It is a bit ridiculous to react to a vulnerability being found in a product by replacing it with another. See the classic WW2 bomber survival survey problem for the reason why. Essentially, you're reacting to one rare and unlikely incident as if it were definitive evidence of the security of Bash against that of other shells.

Keep in mind that visible exploits say absolutely nothing about the number of undisclosed ones and about the number of existing vulnerabilities in software. It could be that Bash is bug-ridden or it could be that after going under scrutiny is it entirely free of vulnerabilities. The problem is noone is able to make any such claim until all the code of all the shells has been thoroughly examined or even better proved to be correct.

You'd be better off with metrics on the quality of the code being written by each project and on their ability to detect and fix bugs and to respond to critical incidents rather than speculating over a handful of vulnerabilities.

Deer Hunter
  • 5,297
  • 5
  • 33
  • 50
Steve Dodier-Lazaro
  • 6,798
  • 29
  • 45
  • 5
    What worries me about `bash` is that the feature that triggered this bug is asking for troubles *by design*; the fact that this feature has been deemed a good idea by the development team casts shadows over the general design philosophy of such shell. – Matteo Italia Sep 27 '14 at 17:22
  • _planet_ should be plane. Basically all the planes coming back had not been hit in the fuel tanks, engine nacelles, bomb bay, aft near the empennage controls, or cockpit area. Statistical shadow shows vulnerability, eh? It was the opposite of what could be visibly measured. – Fiasco Labs Sep 27 '14 at 17:23
  • Survivors *design* the shadow of the death. – dan Sep 27 '14 at 18:19
  • 2
    This would be true if bash and the proposed alternatives had the same attack surface. But dash has markedly fewer features, and thus offers less opportunity for vulnerabilities. – Gilles 'SO- stop being evil' Sep 27 '14 at 21:29
  • @MatteoItalia I won't argue against such an argument... However I'm much more dubitative about people who execute their own code in an environment manipulated by principals with lesser privileges :-) – Steve Dodier-Lazaro Sep 28 '14 at 02:28
  • @Gilles indeed. – Steve Dodier-Lazaro Sep 28 '14 at 02:30
2

Debian and Ubuntu already do this by using dash instead of bash for /bin/sh. Of course, this substitutes a less-inspected codebase in a key piece of system infrastructure, so it's a distinct possibility that it has unknown vulnerabilities of equal impact to the recent bash issues.

David
  • 15,814
  • 3
  • 48
  • 73
  • 4
    Less-inspected? I don't see any justification for that claim. Clearly bash was not inspected for security *ever* since nobody was aware of this silly "function import" "feature", which would have been a huge red flag to anybody reading it for security. – R.. GitHub STOP HELPING ICE Sep 27 '14 at 13:26
  • 4
    @R.. Not quite nobody: [Sudo 2004-11-11](http://www.sudo.ws/sudo/changes.html) env.c: strip exported bash functions from the environment. Presumably they didn't notice the Shellshock flaw, but they were aware that this was a juicy attack surface. – Gilles 'SO- stop being evil' Sep 27 '14 at 21:27
  • 1
    @Gilles: Nice find. Is there any indication that this was discussed in the security community at the time, or was it just internal to sudo development? – R.. GitHub STOP HELPING ICE Sep 27 '14 at 21:31
  • 1
    @R.. I have no idea. I only discovered it myself recently while checking on the potential attack vectors for Shellshock, I was wondering why sudo wasn't in the commonly-published lists. – Gilles 'SO- stop being evil' Sep 27 '14 at 21:34
2

Anything you do about this vulnerability should be based on an analysis of actual potential risk vectors. Just using the shell as your interactive shell, to be extreme, carries no risks from this bug at all.

The bug only exists when some program allows a hostile party to control the contents of environment variables as seen by an invocation of the shell. For example, a web server that sets an environment variable to the value of of the user agent header from a request, and does not sanitize it. If you run such a service, it makes sense, with or without this bug, to use the simplest shell possible. The less there is to the shell, the less places there could be security exposures. Of course, it would be more better if the web server was running in a jail that made this entire question moot. So if you must run a web server or something like it that launches shells in un-sandboxed environments, shrinking your exposure by running the simplest available shell makes sense.

bmargulies
  • 327
  • 1
  • 7