Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

81–90 of 432 posts

Re: CVE-2014-6271: Remote code execution through bash

#81
post #42

I have a feeling this is blown out of proportion. Who's running bash setuid exactly? Right. Who's running shell CGIs today? Right. So.. who has an example of common scripts that are executed remotely in most servers while accepting remote environment? Til then, the panic seems unjustified...

Google brings up 410 .bash CGIs. Every one of them is almost guaranteed to be vulnerable at this point. Of the 1.2 million .sh CGIs, some are surely vulnerable. By this time, many of them are already be in the process of being owned.

CGIs are likely the smallest piece of the vulnerable hosts here. This is going to stick around as a local vulnerability on the plentiful supply of under-patched Linux boxes for a long time.

Re: CVE-2014-6271: Remote code execution through bash

#83

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?

Re: CVE-2014-6271: Remote code execution through bash

#84
post #71
post #35

Earlier quoted context omitted.

Apparently, no. When it does, it should appear at http://lists.centos.org/pipermail/centos-announce/2014-Septe... (if you admin CentOS servers, it can be a good idea to subscribe to that list).

Yes: http://lists.centos.org/pipermail/centos-announce/2014-Septe... Verify your shasums before trusting a command line off the internet but: rpm -Uvh http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/... http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/...

Looks like it works. I guess it is okay that after the close quote the command still runs even though it is not terminated

     env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
     bash: warning: x: ignoring function definition attempt
     bash: error importing function definition for `x'
     this is a test

Re: CVE-2014-6271: Remote code execution through bash

#85
post #83

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?

It will be once they release a patch, yes

https://security-tracker.debian.org/tracker/CVE-2014-6271

Re: CVE-2014-6271: Remote code execution through bash

#86
post #17

It 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 arguments. Cut out the middle man and pass the arguments directly. It will save you a lot of stupid bugs.

Re: CVE-2014-6271: Remote code execution through bash

#87
post #83

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?

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...).

Re: CVE-2014-6271: Remote code execution through bash

#89
post #87
post #83

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?

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

Re: CVE-2014-6271: Remote code execution through bash

#90

Earlier quoted context omitted.

Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.

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
Post reply on HN