Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CVE-2014-6271: Remote code execution through bash

seclists.org

Post reply on HN
Print view View original

71–80 of 432 posts

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

#71

Post by skorgu »

cesarb wrote: post #35
ck2 wrote: post #18

Has the redhat patch been pushed through centos yet?

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

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

#74

Post by justincormack »

mhurron wrote: post #59
justincormack wrote: post #21

Earlier quoted context omitted.

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 a sane environment /bin/sh should not be bash Why, other than it is not the shell of the day?

First it encourages people to use bash specific stuff that is non Posix. Second it is a huge bloated bit of code thats ok as user interface, but scripts should use something that is more minimal. To avoid this sort of issue.

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

#76

Post by claudius »

[deleted] wrote: post #53
aroch wrote: post #30

Earlier quoted context omitted.

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

[deleted]

Yes, the printing of “vulnerable” in the 4th line of your code snippet.

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

#78

Post by jamroom »

lmz wrote: post #48
ars wrote: post #32

Earlier quoted context omitted.

Lots? Really? PHP was one of the first to have a dedicated apache module. Perl is much more likely to be CGI.

I seem to recall cPanel defaulting to suPHP (which uses CGI).

Yeah this is true - a lot of hosting providers run PHP as a CGI as it allows them to run the PHP process under the user account (although it is very slow, and RUID2 is a better solution).

If you're not running mod_cgi can this affect the system in any way?

Thanks!

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

#79

Post by jamroom »

nknighthb wrote: post #36
huhtenberg wrote: post #22

Earlier quoted context omitted.

> hardly anybody uses it anymore anyway Lots of PHP setups do.

They would be too slow to be useful at any kind of real load. Are you sure you're not thinking of FastCGI? That doesn't pass data through the environment, it goes over a socket.

Yeah - it is really slow, but a surprisingly large number of hosting providers run it that way under cPanel.
Post reply on HN