3 ms·

I can think of a few ways this could be a problem if you sudo. Sudo is configured to whitelist environment variables, so just figure out which ones are on the

I can think of a few ways this could be a problem if you sudo. Sudo is configured to whitelist environment variables, so just figure out which ones are on the whitelist, or find half the people who have alised sudo='sudo -E'. From man sudo on OS X: SECURITY NOTES sudo tries to be safe when executing external commands. Variables that control how dynamic loading and binding is done can be used to subvert the program that sudo runs. To combat this the LD_*, _RLD_*, SHLIB_PATH (HP-UX only), and LIBPATH (AIX only) environment variables are removed from the environment passed on to all commands executed. sudo will also remove the IFS, CDPATH, ENV, BASH_ENV, KRB_CONF, KRBCONFDIR, KRBTKFILE, KRB5_CONFIG, LOCALDOMAIN, RES_OPTIONS, HOSTALIASES, NLSPATH, PATH_LOCALE, TERMINFO, TERMINFO_DIRS and TERMPATH variables as they too can pose a threat. If the TERMCAP variable is set and is a pathname, it too is ignored. Additionally, if the LC_* or LANGUAGE variables contain the / or % characters, they are ignored. Environment variables with a value beginning with () are also removed as they could be interpreted as bash functions. If sudo has been compiled with SecurID support, the VAR_ACE, USR_ACE and DLC_ACE variables are cleared as well. The list of environment variables that sudo clears is contained in the output of sudo -V when run as root. From man sudo on Ubuntu Linux: Note, however, that the actual PATH environment variable is not modified and is passed unchanged to the program that sudo executes.

ClashTheBunny 12y ago
Specifically, here's Debian's output of sudo sudo -V: Environment variables to preserve: XAUTHORIZATION XAUTHORITY TZ PS2 PS1 PATH LS_COLORS KRB5CCNAME HOSTNAME DISPLAY COLORS Just set any of those on an account with sudo access to something that runs bash. Even if the bash command was something trivial.
- cesarb 12y ago
  That makes me think of another facet of this bug: it can bypass logging by sudo of the executed commands. A quick look at journalctl's output shows that sudo by default, at least on the distribution I'm using, logs only the original user, the tty, the current working directory, the target user, and the command. It does not seem to log the environment variables. So you could use an innocent-looking sudo command (like "sudo ls") to hide doing something else as root, without using obvious commands like "sudo bash" or "sudo -i".
  - ClashTheBunny 12y ago
    Yes, just put a bash script called ls $HOME/bin, put that directory in $PATH, run sudo ls, and off you go... Hopefully you would not be white-listed to run things like that (always put the full path in sudoers), so you will need some sort of "obviously bash" in the log, but we all know what we have done at moments of interaction with paper-cuts. We have probably all lessened our security to ease discomfort here and there.
    - jtgeibel 12y ago
      I've tested this on both Ubuntu 14.04 and CentOS 6.5, and they both sanitize the path variable such that this is not possible. I believe this is controlled via the secure_path setting in your /etc/sudoers file.
    - cesarb 12y ago
      When I ran "sudo ls", the command that was logged was "/bin/ls", so putting a different ls in $PATH would not trick sudo's logging.
- dllthomas 12y ago
  ... didn't the above say "we clear anything that starts with ()"? Doesn't that defang this?

ClashTheBunny 12y ago

Specifically, here's Debian's output of sudo sudo -V: Environment variables to preserve: XAUTHORIZATION XAUTHORITY TZ PS2 PS1 PATH LS_COLORS KRB5CCNAME HOSTNAME DISPLAY COLORS Just set any of those on an account with sudo access to something that runs bash. Even if the bash command was something trivial.

cesarb 12y ago
That makes me think of another facet of this bug: it can bypass logging by sudo of the executed commands. A quick look at journalctl's output shows that sudo by default, at least on the distribution I'm using, logs only the original user, the tty, the current working directory, the target user, and the command. It does not seem to log the environment variables. So you could use an innocent-looking sudo command (like "sudo ls") to hide doing something else as root, without using obvious commands like "sudo bash" or "sudo -i".
- ClashTheBunny 12y ago
  Yes, just put a bash script called ls $HOME/bin, put that directory in $PATH, run sudo ls, and off you go... Hopefully you would not be white-listed to run things like that (always put the full path in sudoers), so you will need some sort of "obviously bash" in the log, but we all know what we have done at moments of interaction with paper-cuts. We have probably all lessened our security to ease discomfort here and there.
  - jtgeibel 12y ago
    I've tested this on both Ubuntu 14.04 and CentOS 6.5, and they both sanitize the path variable such that this is not possible. I believe this is controlled via the secure_path setting in your /etc/sudoers file.
  - cesarb 12y ago
    When I ran "sudo ls", the command that was logged was "/bin/ls", so putting a different ls in $PATH would not trick sudo's logging.
dllthomas 12y ago
... didn't the above say "we clear anything that starts with ()"? Doesn't that defang this?