Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

seclists.org

Post reply on HN
Print view View original

141–150 of 226 posts

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

#141

Post by dspillett »

annnnd wrote: post #134
dspillett wrote: post #130

Earlier quoted context omitted.

> It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. The web server side only comes into play for remote exploits. It is locally exploitable too (though the potential for useful exploits that way is lower, it is still a significant risk).

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 as the user who is setting the ENV variables, and only privileged users should be able to set system-wide ENV vars.

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.

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

#142

Post by clarry »

kalleboo wrote: post #137

I've been trying to exploit our own systems which have PHP web frontends running under apache/mod_php, and in my testing PHP isn't passing through any HTTP_* environment variables at all in calls to system() or exec(). Even just echoing back the result of "env" it doesn't look like I get anything user-supplied whatsoever in there (no HTTP_*) Can anyone more knowledgable confirm what I've seen?

CGI is affected. When using mod_php, the request headers aren't passed via environment.

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

#143

Post by ClashTheBunny »

ClashTheBunny wrote: post #139
annnnd wrote: post #134

Earlier quoted context omitted.

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 as the user who is setting the ENV variables, and only privileged users should be able to set system-wide ENV vars.

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 th…

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.

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

#144

Post by pwg »

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

Not always, this is on Slackware 14.1:

    $ ls -l /bin/sh 
    lrwxrwxrwx 1 _ _ 4 Apr  3 18:13 /bin/sh -> bash*

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

#145

Post by ZoFreX »

annnnd wrote: post #134
dspillett wrote: post #130

Earlier quoted context omitted.

> It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. The web server side only comes into play for remote exploits. It is locally exploitable too (though the potential for useful exploits that way is lower, it is still a significant risk).

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 as the user who is setting the ENV variables, and only privileged users should be able to set system-wide ENV vars.

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.

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

#146

Post by ZoFreX »

arh68 wrote: post #40
stock_toaster wrote: post #25

Earlier quoted context omitted.

It really depends on the *nix you are running. FreeBSD, for example, only had bash as a port and it is not in the base install -- I believe `/bin/sh` is a derivative of ash[1]. [1]: http://en.wikipedia.org/wiki/Almquist_shell

I never really considered the importance of that. It always seemed like some weird crotchety UNIX thing to default to /bin/sh, and usually my first 30 minutes on a FreeBSD box are portsnapping, cd /usr/ports/shells/bash, and a make install clean. Now I get it

The other reason is that bash has dependencies outside the core system and is therefore possible to totally break on FreeBSD. Never change root's shell to bash!

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

#147

Post by jballanc »

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

If you're following the instructions here: http://apple.stackexchange.com/questions/146849/how-do-i-rec...

...then this patch needs to be modified (different line numbers) before it can be applied to the Apple version of bash:

    --- parse.y.old 2014-09-25 13:42:17.000000000 +0300
    +++ parse.y    2014-09-25 13:41:39.000000000 +0300
    @@ -2503,6 +2503,8 @@
       FREE (word_desc_to_read);
       word_desc_to_read = (WORD_DESC *)NULL;
    
    +  eol_ungetc_lookahead = 0;
    +
       last_read_token = '\n';
       token_to_read = '\n';
     }
Testing locally, this appears to mitigate both known (so far) vulnerabilities.

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

#148

Post by cesarb »

ClashTheBunny wrote: post #143
ClashTheBunny wrote: post #139

Earlier quoted context omitted.

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 th…

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 "sudo ls") to hide doing something else as root, without using obvious commands like "sudo bash" or "sudo -i".

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

#149

Post by robinson-wall »

someguy222 wrote: post #117
cft wrote: post #72

Earlier quoted context omitted.

I am seeing: web22 ~> grep "() {" logs/access_log 209.126.230.72 - - [24/Sep/2014:17:16:46 -0700] "GET / HTTP/1.0" 200 5733 "() { :; }; ping -c 11 209.126.230.74" "shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)" 13378 () { :; }; ping -c 23 209.126.230.74 80 74529

very interesting one: 89.207.135.125 - - * () { :;}; /bin/ping -c 1 198.101.206.138"

Yes, I had that one too, also this:

    24.251.197.244 - - [25/Sep/2014:10:07:47 +0000] "GET / HTTP/1.1" 301 178 "-" "() { :; }; echo -e \x22Content-Type: text/plain\x5Cn\x22; echo qQQQQQq"

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

#150

Post by cesarb »

dspillett wrote: post #141
annnnd wrote: post #134

Earlier quoted context omitted.

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 as the user who is setting the ENV variables, and only privileged users should be able to set system-wide ENV vars.

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 t…

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.

Post reply on HN