I don't see the new update on Ubuntu 12.04. What version of bash contains the complete fix? I'm still at 4.2.25(1)-release
http://www.ubuntu.com/usn/usn-2363-1/ - Ubuntu 12.04, bash 4.2-2ubuntu2.3.
Re: CVE-2014-6271 – remote code execution through bash
31–40 of 52 posts
Re: Re: CVE-2014-6271 – remote code execution through bash
#32Debian patched this 8 hours ago, Redhat issued a patch about 3 hours ago, I believe Centos is still vulnerable, Ubuntu 14.10 isn't patched yet, Ubuntu 14.04 was patched about 3 hours ago.
CentOS released a patched bash package around 2AM GMT, something like an hour after RedHat.
Re: Re: CVE-2014-6271 – remote code execution through bash
#33Earlier quoted context omitted.
That test doesn't detect the vulnerability - needs to mention /bin/bash not /bin/sh
Well, maybe you should look at your /bin/sh ls -l /bin/sh lrwxrwxrwx 1 root root 4 Sep 24 08:07 /bin/sh -> bash
I think /bin/sh is /bin/bash on CentOS and RedHat, but Debian, Ubuntu and probably other distros use dash as /bin/sh instead which was never vulnerable.
Re: Re: CVE-2014-6271 – remote code execution through bash
#34My server actually got hacked through this. I patched the first vulnerability quickly (arch linux, just did pacman -Sy bash). The second vulnerability was published overnight, tried to ssh to my box to patch it in the morning: "enter password:" - uh oh, I use public key auth
My server runs a couple of wordpress sites and a rails app - not sure where the vulnerability was exploited but be warned, looks like bots are already crawling for it
Re: Re: CVE-2014-6271 – remote code execution through bash
#35Not having worked with bash (et al) in ages I wonder whether allowing a function definition (even without trailing commands) is not still hole? What if you defined a function 'ls() { evil... }'... could a CGI script making a call to 'ls' actually end up with the function instead of the real 'ls'?
I think the cases where it's still a hole are probably obscure and/or unlikely in the wild, but I definitely think the response to this should have been to disable the feature altogether. It's a terrible idea and I'm really curious if anything actually uses it and should be using it .
It's used to export functions from one instance of bash to a child. Do you think that that's a terrible idea, or do you have a better idea of how to implement it?
(The fix changes it so that exporting is done through specially named variables. Instead of exporting `x='() { :; };`, it now exports `BASH_FUNCTION_x()='() { :; };'`.)
Re: Re: CVE-2014-6271 – remote code execution through bash
#36My server actually got hacked through this. I patched the first vulnerability quickly (arch linux, just did pacman -Sy bash). The second vulnerability was published overnight, tried to ssh to my box to patch it in the morning: "enter password:" - uh oh, I use public key auth My server runs a couple of wordpress sites and a rails app - not sure where the vulnerability was exploited but be warned, looks like bots are a…
Huh. I thought the second issue did not have an exploit? That when set, all would happen was that running "X Y" via a shell could instead run "Y > X " ?
Re: Re: CVE-2014-6271 – remote code execution through bash
#37My server actually got hacked through this. I patched the first vulnerability quickly (arch linux, just did pacman -Sy bash). The second vulnerability was published overnight, tried to ssh to my box to patch it in the morning: "enter password:" - uh oh, I use public key auth My server runs a couple of wordpress sites and a rails app - not sure where the vulnerability was exploited but be warned, looks like bots are a…
Huh. I thought the second issue did not have an exploit? That when set, all would happen was that running "X Y" via a shell could instead run "Y > X " ?
If the attacker can control a list of arguments and an env var value, you're back to arbitrary command execution, albeit redirected somewhere. That sounds suspiciously insecure even without bash vulnerabilities, though. Would be interesting if GP knows what they used.
Re: Re: CVE-2014-6271 – remote code execution through bash
#38Earlier quoted context omitted.
Huh. I thought the second issue did not have an exploit? That when set, all would happen was that running "X Y" via a shell could instead run "Y > X " ?
If the attacker can control a list of arguments and an env var value, you're back to arbitrary command execution, albeit redirected somewhere. That sounds suspiciously insecure even without bash vulnerabilities, though. Would be interesting if GP knows what they used.
I have no idea, I wasn't able to access any logs or anything.
It's possible they had already installed a backdoor using the first vulnerability before I patched it, or perhaps something else entirely (though that's a little too coincidental)
Re: Re: CVE-2014-6271 – remote code execution through bash
#39Is any fix going to be rolled out to older no longer supported versions of Linux? I know they're out of support but I think this is a special case and deserves the attention.
Highly unlikely. Anyone still running an out-of-support instance who isn't manually applying updates is already vulnerable to other unpatched issues anyway, and those held back on old versions who are manually applying security updates (by compiling their own from upstream source and such) will already be on the ball with this one.
Re: Re: CVE-2014-6271 – remote code execution through bash
#40I don't understand. I see that the fix causes bash to ignore function definitions in the environment variable. But why should bash interpret the variable's content in the first place, and not treat it as a string? I suppose that someone can use eval if he really wants to execute it.