The three options listed in the CERT release (AcceptEnv TERM and SSH_ORIGINAL_COMMAND) are all server-side options. If none of these are set on a host (and no http vector is available) is the host secure, even if Bash remains unfixed? If I set AcceptEnv=HACK on the openssh server, shouldn't this work?

HACK='() { :;}; /usr/bin/touch /tmp/illegal' ssh user@host
  • $ LC_ALL='() { :; }; echo vulnerable' ssh [hidden] true / vulnerable
    – user45655
    Commented Sep 25, 2014 at 18:43

2 Answers 2


You should be safe from ssh side, but there are other vectors as well, like dhclient-script.

By the way, you are only really "vulnerable" through SSH if you have users with restricted access (e.g. chroot or sftp-only). If all your users have full shell access, then even though they may run commands using this exploit, they could do that anyway.

  • 1
    Rephrasing my previous comment: does OpenSSH execve to Bash with the user's identity and the accepted environment variables (in which case it's fine) or does it execve to Bash with its own identity and then su's to the user's (in which case privilege escalations are possible)? Commented Sep 26, 2014 at 14:08
  • 1
    @SteveDL: It can't assume that the user's shell has any sort of su command, so it has to change UID before spawning the shell.
    – Ben Voigt
    Commented Sep 26, 2014 at 14:17
  • In which case it would not be vulnerable, would it? Commented Sep 26, 2014 at 14:58

You're correct, as far as I can tell. If AcceptEnv is not set then a remote client cannot get the SSH server to process any environment variable.

Note that you can execute a command through SSH as an authenticated client and get that command to load up your crafted environment variable. So if you have any setuid/setgid binary running a Bash script, this could be used to compromise your system by an authenticated user either locally or remotely through SSH.

  • 2
    It should not be possible to have setuid bash scripts, because only "real" executables can be made setuid. Of course you could still have a wrapper which starts this bash script and does not clean the environment before starting the script. Commented Sep 27, 2014 at 5:36
  • I didn't know that! Thanks @SteffenUllrich, I'm adding a link to my answer explaining how this could happen. Commented Sep 27, 2014 at 11:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .