So if a machine is not running a web server, does that mean that machine is not vulnerable?
CVE-2014-6271: Remote code execution through bash
101–110 of 432 posts
Re: CVE-2014-6271: Remote code execution through bash
#102Earlier quoted context omitted.
I don't know if Ubuntu has pushed a patched version of bash, but bash is what you should update. Someone already posted a way to test whether your version is vulnerable. You might also look into changing the default shell (but beware, scripts with bashisms in them...).
Ubuntu pushed the update around noon 4.3-7ubuntu1.1
Really? I haven't been able to find any notice of that, and on 14.04 LTS if I run `sudo apt-get install --only-upgrade bash` I'm still vulnerable.
Re: CVE-2014-6271: Remote code execution through bash
#103Earlier quoted context omitted.
It's fixed in Debian as well.
I am not so sure. Debian sid (i386) with current updates, the example test shows I am still vulnerable. 4.3-9 bash
I ran
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test
apt-get update
apt-get install bash
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
Edited: Seems like jvreeland has a clearer picture: https://news.ycombinator.com/item?id=8362309
Re: CVE-2014-6271: Remote code execution through bash
#104If 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?
A good question that so far nobody has answered (as of right now).
Re: CVE-2014-6271: Remote code execution through bash
#105Earlier quoted context omitted.
I don't know if Ubuntu has pushed a patched version of bash, but bash is what you should update. Someone already posted a way to test whether your version is vulnerable. You might also look into changing the default shell (but beware, scripts with bashisms in them...).
Ubuntu pushed the update around noon 4.3-7ubuntu1.1
sudo apt-get update && sudo apt-get upgrade
Re: CVE-2014-6271: Remote code execution through bash
#106It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time. Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.
I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your…
The API for system() is not great, but the execve family of functions are not drop-in replacements since they don't take care of forking, changing the signals, and waiting. As long as you're not passing arguments from outside sources to the command, using system() should be OK.
Re: CVE-2014-6271: Remote code execution through bash
#107Earlier quoted context omitted.
Ubuntu pushed the update around noon 4.3-7ubuntu1.1
Really? I haven't been able to find any notice of that, and on 14.04 LTS if I run `sudo apt-get install --only-upgrade bash` I'm still vulnerable.
Re: CVE-2014-6271: Remote code execution through bash
#108Earlier quoted context omitted.
Ubuntu pushed the update around noon 4.3-7ubuntu1.1
Really? I haven't been able to find any notice of that, and on 14.04 LTS if I run `sudo apt-get install --only-upgrade bash` I'm still vulnerable.
Ah, looks like I needed to run `sudo apt-get update` first.
Re: CVE-2014-6271: Remote code execution through bash
#109My 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
If i remember correctly Apples stopped updating bash in OSX a long time ago I wonder if this will get fixed.
Re: CVE-2014-6271: Remote code execution through bash
#110It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time. Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.
I am sure tons of people reading already know this, but I have a habit of saying this everywhere I see system() mentioned anywhere on the internet, just in case somebody reading is tempted to use it: system() is evil, please for the love of god never use it. If you need to invoke another program use execve() and friends. The versions that end in -p will even check PATH for you. You don't need a shell to evaluate your…
There's nothing wrong with using system anywhere you would happily cover your eyes and paste the string content into a shell. That shouldn't be many places, if anywhere, in production software. It's fine for simple things that would've been shell scripts anyway but for the need to XYZ.