261–270 of 432 posts
Is someone from Heroku online here right now? My apps are all affected and since I am trusting Heroku with this, I am hoping they patch the system as soon as possible.
[1] - https://twitter.com/jacobian/status/514865870649061376
Lots of web stuff spawn shells setting environment variables to stuff in HTTP headers. LC_TIME with some time zone settings might be one.
I'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…
so basically turn off AcceptEnv in sshd_config?
Also don't use bash for running any scripts. You never should anyway, in a sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash which is not vulnerable. Unfortunately the Redhat derived distros do use bash as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash is for users not scripts.
In FreeBSD, it is tcsh in sh mode. Bash does the same too when invoked as sh[0]. It's POSIX compliant with extensions. There's still all the shell's code there, it's just that some of it is switched off by default, or its behaviour modified, to be compliant.
[0] http://www.gnu.org/software/bash/manual/html_node/Bash-POSIX...
Earlier quoted context omitted.
I'm not seeing this on zsh 4.3.17. Exactly what did you run to see this?
They probably ran env x='() { :;}; echo vulnerable' bash -c "echo this is a test" but failed to spot that the second command invokes bash not zsh. My tests suggest that neither zsh 4.3.17 or 5.0.6 (the versions that ship with Debian stable & testing respectively) are vulnerable to this exploit - if you replace bash with zsh in the test oneliner then the code after the end of the function definition in the environment…
Earlier quoted context omitted.
"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.
That's ridiculous. You may as well say that every time you put a python script up, you're exposing the entire Python runtime and deserve to get 'pwned'. The scope of the risk is limited to script that you write, whether bash or Python.
Earlier quoted context omitted.
Any library anywhere in any application you run that calls out to bash that is called by any other library in that application, so long as that application is somehow hooked up to a web server, is potentially an unauthenticated GET request away from code execution; the exploit for this is potentially so simple that attackers can craft a single request, spider the Internet, and collect shells from applications you run…
So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"? "is potentially an unauthenticated GET request" Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?
(Note I'm not claiming this is the "worst bug ever"... there's stiff competition for that claim. But most of the rest of the "worst bug ever"s I can think of are some point that failed, some particular thing you could do for full root access or something. I can't think of anything else with this sheer staggering surface area.)
Earlier quoted context omitted.
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?
If you just want to upgrade bash, and prevent services like nginx, fpm, and apache from being restarted in production, you can run `sudo apt-get update && sudo apt-get install --only-upgrade bash` 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?
I don't think it will, for a couple of reasons. OpenSSL is integrated into other services as a library, while bash would be called as an external application. I also noticed that once I upgraded bash, the proof of concept stopped working in a terminal I opened prior to the upgrade.
So if a machine is not running a web server, does that mean that machine is not vulnerable?