Hacker News Reader

Comment by flebron | Hacker News Reader

Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.

View on HN

How are you testing it? If you're just pasting one of the proof-of-concept lines into zsh, such as this one:

    env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

...then you're really just executing bash. Replace "bash" in the line above with "zsh" and the "vulnerable" line is not printed.

No, it's not printed in your trivial example, but if you replace the simple "echo" command with any bash script, or any executable that calls a bash script, or any executable that invokes another program that calls a bash script, or ... then you're screwed.

Even with the "zsh", this should print "vulnerable":

  env x='() { :;}; echo vulnerable' zsh -c "bash -c true"

You don't have to use bash explicitly. It might be called by some application or library. For example, if your default shell is a bash, this will work too:

  env x='() { :;}; echo vulnerable' zsh -c "python -c 'import os; os.system(\"true\")'"

Right, the point being that bash is vulnerable, not zsh (as was suggested by the post I was replying to). I'm not claiming that using zsh as your interactive shell somehow makes you immune.

I see this in zsh 5.0.0 on Ubuntu, and on OSX as well! zsh 5.0.2 (x86_64-apple-darwin13.0)

I'm not seeing this on zsh 4.3.17. Exactly what did you run to see this?

They probably ran

  env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

but failed to spot that the second command invokes bash not zsh.

My tests suggest that neither zsh 4.3.17 or 5.0.6 (the versions that ship with Debian stable & testing respectively) are vulnerable to this exploit - if you replace bash with zsh in the test oneliner then the code after the end of the function definition in the environment variable is not executed.

That's it, I am an idiot today. (and more days probably)

Reply on news.ycombinator.com