38

Does the Shellshock Bash bug affect ZSH?

Is upgrading Bash the only solution?

bwDraco
  • 45,747
  • 43
  • 165
  • 205
marflar
  • 533
  • 4
  • 11
  • according to [this answer](http://unix.stackexchange.com/a/59431/81612) on a different exchange, ZSH does not export functions. Since the Shellshock bug was caused by this bash specific feature, other shells that lack it should probably not be affected. – lzam Sep 29 '14 at 02:27

4 Answers4

36

No, it doesn't affect ZSH.

You still MUST update bash as most of the system scripts are written for bash and vulnerable to the shellshock bug.

To test your ZSH do this:

env x='() { :;}; echo vulnerable' zsh -c 'echo hello'

What exactly does this code do?

  1. env x='() { :;}; echo vulnerable' creates an environment variable with known bug using command in the end of variable
  2. zsh -c 'echo hello' launches ZSH shell with simple hello (and evaluating all env variables including x)

If you see output:

vulnerable
hello

Then your ZSH is vulnerable. Mine (5.0.2) is not:

$ env x='() { :;}; echo vulnerable' zsh -c 'echo hello'
hello
mente
  • 476
  • 3
  • 5
  • Thanks a lot. I found my Ubunutu 10.10 machines are all vulnerable, but my Centos 6.4's are not... – marflar Sep 25 '14 at 14:47
  • 1
    if we use zsh but still we have bash in our system! do we need to worry about that? if not why? – Dineshkumar Sep 26 '14 at 05:21
  • 16
    @Dineshkumar: yes, you should still worry & patch. The reason is that even if *you* are using zsh, other programs (dhcp was mentioned, many PHP applications will probably do, and lots of other programs and scripts on a typical Linux machine) will still call bash. (In fact, they shouldn't, but it has become a bad habit.) – hans_meine Sep 26 '14 at 08:16
  • @hans_meine, why is it a bad habit? If one is writing a script using say a special syntax/feature of a certain shell would it not be inappropriate to call for `#!/bin/sh` instead of the interpreter your script is for? – Ghanima Sep 26 '14 at 13:39
  • 2
    @stephenmurdoch Ubuntu 10.10 is quite old and hasn't been supported for over 2 years... – Izkata Sep 26 '14 at 13:55
  • 2
    @Ghanima: calling `bash` is a bad habit for system utilities because bash is not guaranteed to be installed; `/bin/sh` is the standard shell and is required to be a correct POSIX shell interpreter. – Phil Hord Sep 26 '14 at 14:40
  • @phord, sure about system utils, but if I were to write a sript based on some idiosyncrasies of `bash` (that could be considered a bad habit on its own) it would however be wise to call `bash` as interpreter and not `/bin/sh`. – Ghanima Sep 26 '14 at 14:46
  • 2
    fwiw - When bash is run as /bin/sh, it runs as a POSIX-compatible shell. In this mode, however, it also has the bug. `env x='() { :;}; echo vulnerable' sh -c 'echo hello'` – Phil Hord Sep 26 '14 at 15:04
  • Also, I think it's worth noting somewhere here that it's entirely possible that zsh has *different* vulnerabilities, which may in future be identified. – lindes-hw Sep 26 '14 at 17:54
  • @lindes-hw It's entirely possibly for every piece of software that it has the same or different vulnerabilities which may in the future be identified. – OJFord Sep 26 '14 at 18:36
  • 1
    @Ghanima I called using bash a "bad habit", because often using /bin/sh and the *restricted set of POSIX shell features* (no shellshock) would totally suffice and make scripts work on systems with non-bash shells, too. Many people are careless in this respect, and just assume a "standard Linux system" with bash. Second, I would always try to directly call other programs, instead of going through the shell. Often the shell is unnecessarily used (e.g. from PHP or Python) in order to call some external program ("perform a command") when it would be much more secure not to go through the shell. – hans_meine Sep 26 '14 at 21:30
  • @phord Thanks for pointing out that bash also features the shellshock bug when called in POSIX mode. I hoped it would not (but would not have placed any bet ;-) ). – hans_meine Sep 26 '14 at 21:32
  • @OllieFord: Yes, that was precisely the point I was trying to get at. Basically, I wanted to make sure that this answer wasn't interpreted as saying "No, zsh is not vulnerable to attack", and instead interpreted as "No, zsh does not have this particular vulnerability". – lindes-hw Sep 29 '14 at 17:50
6

From this link:

You can determine if you are vulnerable to the original problem in CVE-2014-6271 by executing this test:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'

If you see the word vulnerable in the output of that command your bash is vulnerable and you should update. Below is a vulnerable version from OS X 10.8.5:

env x='() { :;}; echo vulnerable' bash -c 'echo hello'
vulnerable
hello

The following output is an example of a non-vulnerable bash version.

$ env x='() { :;}; echo vulnerable' bash -c 'echo hello'
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
hello
vectorsize
  • 161
  • 1
  • Also note that when patching bash following the instructions on the link zshell stopped being vulnerable, which makes me think that zshell uses bash at its core. – vectorsize Sep 25 '14 at 12:55
  • 9
    Note that there has been a [followup](https://twitter.com/taviso/status/514887394294652929): ``env X='() { (a)=>\' bash -c "echo date"`` will, on a patched bash and despite throwing lots of errors, produce a file called ``echo`` which contains the date. I don’t want to know why. – Jonas Schäfer Sep 25 '14 at 13:06
  • @Jonas Wait, produce a *file*?! I understand the vulnerability, but that's just bizarre. – Doorknob Sep 25 '14 at 17:08
  • @Doorknob My assumption is (I have not looked at code or patches), the parser keeps some state when erroring out in the broken function definition in the environment variable. Namely, the > and the \ (or their meaning) seem to be kept. The \ seems to escape something, so it boils down to executing ``> echo date``. [See also this oss-security post](http://www.openwall.com/lists/oss-security/2014/09/24/40) – Jonas Schäfer Sep 25 '14 at 17:10
  • 5
    @vectorsize `zsh` does *not* use `bash` at its core. `bash` is explicitly called in your examples. It does not matter which shell you are using to run these lines. This vulnerability affects the newly started bash shell, not the shell it is run from. – Adaephon Sep 25 '14 at 20:44
  • 2
    @Adaephon So one would like to replace ``bash`` in the examples by ``$SHELL``. – Jonas Schäfer Sep 25 '14 at 21:07
  • @adaephon of course!! you are right, how stupid of me ^^ – vectorsize Sep 25 '14 at 22:07
6

The binary is not affected

It does not affect zsh as the shell executable, because it's source code never contained the error.
There are many similaritys between bash and zsh, but they werer implemented independent from each other. The same feature is implemented in two different ways, and - more important in this context - usually with different errors.

But the interactive use is

Indirectly it does affect working interactively with the zsh shell in a terminal almost as much as working with bash.

The use of bash is just so common that one can hardly avoid to call it.

Too many uses to avoid

  • scripts you know and expect to use zsh, but actually contain bash.
  • lots of shell scripts that use #!/bin/bash to specify bash as the interpreter.
  • lots of commands that you assume are binaries, but are shell scripts, some of them using bash.

  • in many places where a shell is executed explicitly, bash may be used, and possibly required.

    • like complex xargs commands, or git aliases involving arguments
    • default shells of terminal emulators
    • shell of users you sudo to
    • etc.
Volker Siegel
  • 1,504
  • 11
  • 21
4

No, Shellshock does not affect zsh directly.

However many environments that use zsh as the default shell also have bash installed. Any shell, including zsh, can be used to spawn a compromised bash shell:

zsh ❯ env X='() { (a)=>\' sh -c "echo date"; cat echo
sh: X: line 1: syntax error near unexpected token `='
sh: X: line 1: `'
sh: error importing function definition for `X'
Fri 26 Sep 2014 12:05:57 BST

To defend against this you should patch, uninstall or disable any redundant versions of bash. You could disable the system bash install with chmod:

$ chmod a-x /bin/bash

However, it is common for scripts to explicitly call bash. Scripts that do this, and those that use bash-specific scripting features, will fail if bash is not available. Patching is the best solution.

joews
  • 141
  • 3
  • it seems that zsh implicitly use bash for "`importing function definition`" ? I also tested with ssh-server injection: `ssh testuser@localhost '() { :;}; echo "$SHELL"'` where I set the `testuser`'s login shell to `/bin/zsh`, and it echoes `/bin/zsh` – Bossliaw Sep 28 '14 at 18:25