Shellshock plus sudo/su environment whitelist bypass - big problem?

Question

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

Or:

• 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.

Answer 1

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.

Answer 2

@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 
#!/bin/bash-shellshock
set

To confirm, without sudo:

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

(not sure why "busted" appears twice)

With sudo:

$ export MAIL="() { :;} ; echo busted"; sudo ./sudoset.bash | head -3
BASH=/bin/bash-shellshock
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()

But the MAIL variable is whitelisted as you describe:

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

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

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