Live data from Hacker News

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

seclists.org

61–70 of 226 posts

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

#61

Earlier quoted context omitted.

I have a security warning from Chrome on my phone as of now. Maybe you want to look into that!

Thanks for the heads up - I'll take a look!

If you use one of several popular cheap SSL providers, you need to add some intermediate certs to your server's SSL store or Android will show those warnings. It's pretty lame.

https://knowledge.rapidssl.com/support/ssl-certificate-suppo...

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

#62
It looks like the important part of the patch (bash43-025) is here:

In builtins/evalstring.c:

    if ((flags & SEVAL_FUNCDEF) && command->type != cm_function_def)

In variables.c:

    parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);
So what the patch does is create a special mode of parse_and_execute() where it's supposed to only evaluate function definitions. A better option would be to add a flag to parse_and_execute() that disables it from attempting any execution completely, not just function definitions.

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

#63
I run an Ubuntu server in my closet as a general-purpose file server and such, mostly just for my own use or for sending files to friends. I have just turned it off and disabled all port forwards to it, and I will wait at least a few days and check for a more definitive fix before opening it back up to the internet. I recommend anyone in a similar situation do the same.

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

#64
post #48

An accepted patch has been released in the form of 4.3-9.1 [1]. It's available on debian everywhere except oldstable. [1] http://osdir.com/ml/general/2014-09/msg47743.html

That's the previous patch, and it didn't fix all the cases. Far as I know, the new one is still unpatched, and people are carefully going through the thicket of string parsing to try to fix it for good.

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

#65

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.

Look at the original announcement from earlier today. This was a known issue and responsible disclosure was exercised -- the issue didn't become public until 5 minutes after the embargo was lifted (i.e., 5 minutes after it was agreed the issue and patch would go public). Since it's so easy to exploit this bug, it'd be impossible to release a patch without people taking notice and immediately beginning to exploit vuln…

Chet (bash maintainer) has indicated that this issue is different to the original CVE.

The problem is the first issue altered people to the fact the the function var parsing was a interesting previously-unpublicized attack vector, and they started looking for more funkiness there.

It would have been nice if the response to the first issue had been to do a thorough and complete testing of the parsing code, but it's not really surprising that it wasn't.

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

#66
post #18

OK two questions: 1. Does zsh (or other shells) also have these kind of string processings where bugs are likely? 2. Is there a way to completely remove bash from the system and use zsh (or other shells) instead?

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

Debian also has a minimalist /bin/sh (via dash), but unlike FreeBSD they do ship bash in the base install, as the default interactive shell. Which is the default interactive shell doesn't matter much, since interactive shell usage isn't the likely vector of this exploit. However some Debian packages may explicitly call bash (rather than /bin/sh), since they can assume it's in the base install, while we know for sure no base FreeBSD packages do. I'm not sure whether anyone's done a survey yet of which Debian packages shell out to bash vs. dash vs. nothing.

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

#67

I run an Ubuntu server in my closet as a general-purpose file server and such, mostly just for my own use or for sending files to friends. I have just turned it off and disabled all port forwards to it, and I will wait at least a few days and check for a more definitive fix before opening it back up to the internet. I recommend anyone in a similar situation do the same.

No need to go to that length. Ubuntu uses dash as its standard /bin/sh. If you're super paranoid, chmod /bin/bash to 000 and fix any broken scripts that call that shebang; most likely, they don't use any bashisms and can use the stock bourne shell.

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

#68

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

Debian also has a minimalist /bin/sh (via dash), but unlike FreeBSD they do ship bash in the base install, as the default interactive shell. Which is the default interactive shell doesn't matter much, since interactive shell usage isn't the likely vector of this exploit. However some Debian packages may explicitly call bash (rather than /bin/sh), since they can assume it's in the base install, while we know for sure…

I think Android uses mksh[1] these days too.

[1]: http://www.all-things-android.com/content/mirbsd-korn-shell-...

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

#69

OK - so assuming that there isn't going to be a single patch which fixes all possible / related bugs any time soon. Options? - Change /bin/sh to something else. (CentOS has BASH as default, alas...) - Filter out unknown, or suspicious looking HTTP vars / env vars at varnish/apache/nginx level, somehow... (doesn't stop other services) - Figure out some clever SELinux configuration that blocks it. I wonder how much wou…

Ubuntu 10.04LTS has dash as the default shell, as does Debian Squeeze (oldstable).

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

#70
post #21

What tools are people using to track and push out security updates, if any? Right now I only have a few servers to administer so apticron is sufficient for notification and upgrading isn't a burden. Also, does anyone have a way to push out patched packages fast? Imagine that a patch is available, or it's trivial to remove a feature that you're not using, but the distribution hasn't made a package yet. I have been dre…

Since I'm an Ubuntu user, I use Landscape to keep my system up-to-date: https://landscape.canonical.com/

It did the patching for me during the night (I told it to do so for security updates), so I woke up to already patched systems.

Full disclaimer: I work for Canonical.

Post reply on HN