Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

21–30 of 432 posts

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

#21
post #3

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.

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

#22

For more info: http://www.csoonline.com/article/2687265/application-securit... This should be fun

CGI has always been an accident waiting to happen, but hardly anybody uses it anymore anyway, and even more rarely in a manner that invokes bash, of all things. I fail to see how "HTTP requests" generically are a vector, and its "Here is a sample" statement is not a link and is followed by... nothing. This article tells me nothing useful other than "don't allow untrusted data into your environment", which we've all k…

> hardly anybody uses it anymore anyway

Lots of PHP setups do.

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

#23
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.

Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions."

[0] http://www.csoonline.com/article/2687265/application-securit...

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

#24

For more info: http://www.csoonline.com/article/2687265/application-securit... This should be fun

CGI has always been an accident waiting to happen, but hardly anybody uses it anymore anyway, and even more rarely in a manner that invokes bash, of all things. I fail to see how "HTTP requests" generically are a vector, and its "Here is a sample" statement is not a link and is followed by... nothing. This article tells me nothing useful other than "don't allow untrusted data into your environment", which we've all k…

People still shell out to do stuff from scripts from all sorts of languages. Unless these sanitize the environment they would be vulnerable.

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

#25
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.

Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-securit...

Likely meaning that the Debian packages for Bash include the vulnerability

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

#26
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.

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

#27
http://www.csoonline.com/article/2687265/application-securit...

Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.

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

#28
post #3

so basically turn off AcceptEnv in sshd_config?

By the time AcceptEnv has any effect, the user is already logged in and can run whatever they want anyway. If you're allowing untrusted users to authenticate to ssh, then, yeah, sure, but you'd be in a niche (and know it).

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

#29
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.

Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-securit...

You're right and my comment was unclear. I'm just saying that the impact on Debian will be less than on distros using /bin/bash for /bin/sh. Of course, even a lessened impact can still be really bad!

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

#30
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.

Do you have a source for that? Some articles [0] claim "This affects Debian as well as other Linux distributions." [0] http://www.csoonline.com/article/2687265/application-securit...

Debian7 doesn't look to be vulnerable by default (if the code snippet can be trusted to work):

    [arch/testbed ~] uname -a
    Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
    [arch/testbed ~]  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
Post reply on HN