1

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

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. – Gilles Oct 3 '14 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. – Stéphane Chazelas Oct 3 '14 at 18:44
0

@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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.