CVE-2014-7169: Bash Fix Incomplete, Still Exploitable

Post by ClashTheBunny » Thu, Sep 25, 2014, 12:27 PM UTC

cesarb wrote: post #148

ClashTheBunny wrote: post #143

Earlier quoted context omitted.

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.

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…

Post by nandhp » Thu, Sep 25, 2014, 12:37 PM UTC

bodyfour wrote: post #78

bodyfour wrote: post #20

Earlier quoted context omitted.

That was one of my first thoughts as well. There is way too much code that's being exposed here. This will be a gift that keeps on giving. For people who want to do environment sanitation, do we know what values can trigger this 'feature'? Is it only "()" as the first two characters? First two non-whitespace characters?

Answering my own question, since I got curious enough to look a the source: if (privmode == 0 && read_but_dont_execute == 0 && STREQN ("() {", string, 4)) So it has to start with that four character sequence exactly. I hope there are patches to webservers, sshd, etc to cleanse environment variables with that value. Even if bash is fixed, it is too risky to send untrusted strings to its parser.

            /* Skip variables with values beginning with () (bash functions) */
            if ((cp = strchr(*ep, '=')) != NULL) {
                if (strncmp(cp, "=() ", 3) == 0)
                    continue;
            }

Post by rst » Thu, Sep 25, 2014, 12:57 PM UTC

mdeslaur wrote: post #82

Proposed patch for CVE-2014-7169 here: http://www.openwall.com/lists/oss-security/2014/09/25/10 I am building bash updates for Ubuntu containing the proposed fix here and will publish them once the fix has been made official: https://launchpad.net/~ubuntu-security-proposed/+archive/ubu...

Post by Wilya » Thu, Sep 25, 2014, 1:16 PM UTC

sjy wrote: post #123

jimrandomh wrote: post #7

With the patched bash, if you run env X='() { (a)=>\' sh -c "echo date" This is equivalent to running date >echo That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token. An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesys…

This assumes that system() is calling bash, but it usually calls /bin/sh, which is often linked to something other than bash (for example, dash is used on recent Ubuntu and Debian installs).

Post by meowface » Thu, Sep 25, 2014, 1:21 PM UTC

canadev wrote: post #53

segmondy wrote: post #47

I'm very annoyed by the founder of this exploit, if you are going to release something as serious as this. At least work on a solution first. Bash source code is open and out there, isn't this suppose to be the "benefits" of open source? Gee.

I don't think that's fair. What if he doesn't know how? He could propose a patch sure, but exploiting a code base may not require in-depth knowledge of it, while making a good patch to it is much more likely to. (I suppose in an ideal situation the fix would be localized to a spot where one would only have to understand a screenful or two of code, but in my experience this is not usually the case.)