Someone please ELI5 (Explain Like I'm 5)?
You're very likely pwned. Upgrade immediately.
CVE-2014-6271: Remote code execution through bash
201–210 of 432 posts
Re: CVE-2014-6271: Remote code execution through bash
#202Earlier quoted context omitted.
$ x='() { :;}; echo vulnerable' bash -c 'echo test' vulnerable test $ pacman -Syu ... $ x='() { :;}; echo vulnerable' bash -c 'echo test' bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x' test Benefits of using an OS with a real package manager.
Just don't turn it off after you've ran `pacman -Syu`, it will never boot again ;)
I know you're just teasing, but I've got a machine with an arch install from over two years ago that's still running great. Just did an -Syyu to get bash updated.
Re: CVE-2014-6271: Remote code execution through bash
#203My OSX Mavericks install appears to be affected: foom:~ steve$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test
My OSX was vulnerable too, but I use Homebrew, and the latest version of bash available via brew update && brew upgrade is patched against this.
If you haven't already been using Homebrew though, you will likely need to move /usr/local/bin infront of /usr/bin in your path, otherwise the old bash would still be used.
Re: CVE-2014-6271: Remote code execution through bash
#204Amazon's Linux distro for EC2 is still waiting for a patch.
EDIT: Finally got things updated. Bulletin can be found here: https://alas.aws.amazon.com/ALAS-2014-418.html
If yum isn't finding the update, try running "yum clean all" and then "yum update bash"
Re: CVE-2014-6271: Remote code execution through bash
#205Earlier quoted context omitted.
The exploit is worse. But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing. Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge. But as it is... I'm not sure?
Google inurl:cgi-bin inurl:.sh
Yeah, that makes sense. Did you try it?
Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are not what we're looking for, mostly forum posts asking about how to make a bash cgi-bin. (Answer from the future: don't).
I _think_ putting quotes around the ".sh" is supported to force the result to really have the period before the sh in the url.
inurl:cgi-bin inurl:".sh"
0 hits
Re: CVE-2014-6271: Remote code execution through bash
#206Earlier quoted context omitted.
As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here: https://securityblog.redhat.com/2014/09/24/bash-specially-cr... The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and run…
You would still need to be able to pass arbitrary data to the bash command, and if your php (or whatever) script does that, you have a lot of other potential problems to worry about.
RedHat security says:
> PHP scripts executed with mod_php are not affected even if they spawn subshells.
https://securityblog.redhat.com/2014/09/24/bash-specially-cr...
Re: CVE-2014-6271: Remote code execution through bash
#207Can someone with mod_security test a regex I wrote that should mitigate this? /\(. ?\)\s \{. ?\}\s \;/ from testing seems to catch any variants that I can think of that can trigger this bug, but I don't have a machine easily available to me at the moment to test with, unfortunately.
Redhat has some here: https://access.redhat.com/articles/1200223
Those regexes seem a bit too fragile for my liking. Adding an extra space between the paren and the bracket breaks it, naming the function breaks it, etc. Plus it has a bigger chance of triggering false positives. It's an okay emergency fix, but I'm positive one can do better.
Re: CVE-2014-6271: Remote code execution through bash
#208Earlier quoted context omitted.
Major impact of this is elevating privileges, both Debian and Ubuntu will be impacted just like any other system. I don't think anybody is worried about software on the system that is using /bin/bash .vs /bin/sh.
Where is the privilege escalation? I get the same results from running id through tripping the bug as I do from running id directly. Edited to add: Also no differences in capabilities when I cat /proc/self/status None of which is to say there is clearly no such vulnerability - I'd just like to understand it if there is.
Privilege escalation is not static.
I know systems where bash has been patched to allow execution by certain users, etc.
With this, you can inject commands before such check takes place.
Etc.
Re: CVE-2014-6271: Remote code execution through bash
#209Earlier quoted context omitted.
Because this allows execution of arbitrary commands from any unsantized environment variable. Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string. GET / HTTP/1.0 User-Agent: () { :; }; rm -rf / Restricted SSH accounts (like the ones used by GitHu…
"A CGI script written in bash" You're killin' me here. If you expose a shell script directly to the network, you're exposing a shell and deserve to be pwned.
If bash is invoked at any point in the response cycle you are pwned; not just if you are directly exposing a shell script. How confident are you that this never happens on any computers anywhere on your network ever?
Re: CVE-2014-6271: Remote code execution through bash
#210Earlier quoted context omitted.
> in a sane environment /bin/sh should not be bash Why, other than it is not the shell of the day?
First it encourages people to use bash specific stuff that is non Posix. Second it is a huge bloated bit of code thats ok as user interface, but scripts should use something that is more minimal. To avoid this sort of issue.
> scripts should use something that is more minimal. To avoid this sort of issue.
Are you also against Perl and Python or does this scripts should be minimal only apply to bash?
> First it encourages people to use bash specific stuff that is non Posix
That's not a problem for most people.
These are reasons you don't like bash, not reasons to not use bash.