The question is: How big a problem is this? Looks pretty big to me.

With the shellshock bug it is possible to bypass the whitelist of known-harmless environment variables in sudo, as well as other routes to execution of code as high-privileged users. For example variables MAIL and DISPLAY are by default propagated by sudo in many configurations (last time I checked - I don't think the latest Debian does).

In the presence of Shellshock, if an unprivileged user, partially privileged user, or malware with unprivileged code-execution can supply any propagated environment variable whatsoever to a shell running as root, he can execute arbitrary code as root.

  • User with limited sudo rights is malicious
  • User sets environment variable such as MAIL to shellshock exploit code
  • Any call to popen, system or bash by any sudo'd command by such a user will now result in arbitrary code execution as root.
  • result is that any sudo rights at all become root access to the system - it does not matter how restricted his access was


  • User gains access to unattended terminal of user with some sudo rights, or
  • Malware gains code execution as an unprivileged user who has some sudo rights
  • Malware/User sets propagated environment variable such as MAIL to shellshock exploit code
  • Any call to popen, system or bash by any sudo'd command by such a user will now result in code execution as root.
  • Does not require knowledge of password - password can be entered later by the victim user after access has ceased.

2 Answers 2


Sudo blocks environment variables that might be bash function definitions (2004-11-11 env.c: strip exported bash functions from the environment), even if the variable name is whitelisted. That's why sudo isn't included in the list of common attack vectors for Shellshock.

A bash script invoked by su to a restricted account can be an attack vector. But there are other problems with a shell script invoked via su. su doesn't strip environment variables such as IFS or PATH (bash doesn't import IFS from the environment, but some other shells do) — or BASH_ENV, which is the name of a file where bash reads commands when it starts up. A shell script invoked via su to a restricted account would need an intermediate wrapper. This wrapper should take care what variables and values it lets through.

  • @sch Dash and posh do. Oct 3, 2014 at 17:01
  • D'oh. I stand corrected. How can they? That was one of the things the Bourne shell used to be bashed on in the 90s. That posh was modified (as it's based on pdksh which doesn't to something as silly) to do that doesn't make sense either. Oct 3, 2014 at 18:44

@Gilles is right. I think the results of this test might be interesting:

I did a test with a very lame script:

$ cat ./sudoset.bash 

To confirm, without sudo:

$ export MAIL="() { :;} ; echo busted"; ./sudoset.bash | head -3

(not sure why "busted" appears twice)

With sudo:

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | head -3

But the MAIL variable is whitelisted as you describe:

$ export MAIL="simpletest"; sudo ./sudoset.bash | grep MAIL

As soon as it contains a function definition, sudo seems to strip it:

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | grep MAIL

You must log in to answer this question.

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