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

141–150 of 432 posts

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

#141

Post by nknighthb »

nitrogen wrote: post #117
nknighthb wrote: post #31

Earlier quoted context omitted.

Unless you're using CGI, your system environment will not be contaminated. CGI is vulnerable because it relies on passing untrusted data in environment variables. No other gateway interface I'm familiar with does.

Are you certain that no method of invoking a dynamic script sets environment variables to values controlled by requests? If so, it sounds like even an innocent call to system("lame a.wav b.mp3") could lead to code execution. Edit: also, you may be surprised to find that some "libraries" are actually wrappers around external binaries (e.g. libgpgme). If any of them used a system() or exec() call that preserves environ…

Are you certain God doesn't exist?

This is far from the first environment variable attack to impact CGI scripts, and CGI's successors have avoided passing data in environment variables.

It's possible some moron decided to create their own CGI replacement using environment variables, but it's not going to be in widespread use.

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

#142

Post by peterwwillis »

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.

Have you ever looked at the backend web interface of some of the most popular residential wifi routers? It's shell script. Why? It's a cheap and accessible interpreted language; no need to clutter up your tiny embedded OS with the huge requirements of php, perl, etc when you have all the tools you need in busybox.

CGI apps execute shell scripts all the time. Even if an app executes an app executes an app executes an app, if that app four layers down runs a shell script, the environment is still passed down. Turtles, dude.

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

#143

Post by larrys »

tptacek wrote: post #128
larrys wrote: post #111

Earlier quoted context omitted.

"If you are responsible for the security of any system, this is your immediate, drop-everything priority." Why don't you explain in plain english exactly why you feel this is the case? "Drop-everything" in other words (or even close to that). Give some scenarios. After all anyone who knows a great deal doesn't need that advice the people who need that advice are ones that don't know enough to know what the impact of…

Any library anywhere in any application you run that calls out to bash that is called by any other library in that application, so long as that application is somehow hooked up to a web server, is potentially an unauthenticated GET request away from code execution; the exploit for this is potentially so simple that attackers can craft a single request, spider the Internet, and collect shells from applications you run…

So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"?

"is potentially an unauthenticated GET request"

Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?

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

#144

Post by dllthomas »

sophacles wrote: post #135
dllthomas wrote: post #98

Earlier quoted context omitted.

That's true of any code execution vulnerability, though - it seems odd to call out the privilege elevation specifically. If that's all the GP meant, then sure, I fully grok.

I think it comes down to a jargon vs technical language thing. In formal settings arbitrary code execution is a different thing from privilege escalation. In casual jargony talk though, security guys tend to equate code execution with privilege escalation with box ownage. Basically it goes "why would anyone not follow the execution -> escalation -> own path?" It's such an automatic assumption, combined with the basic…

None of this seems crazy unlikely, but I'd still like to hear a confirmation that that's what was meant. Especially since korzun was talking specifically about Debian and Ubuntu where bash is only used as a login shell and so presumably those with access could already just run the app.

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

#145

Post by Danieru »

sauere wrote: post #116
matchu wrote: 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?

> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu server? Yes. Patch is out.

You should also reboot to ensure no running instances of bash are vulnerable.

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

#147

Post by dllthomas »

fragmede wrote: post #140
dllthomas wrote: post #98

Earlier quoted context omitted.

That's true of any code execution vulnerability, though - it seems odd to call out the privilege elevation specifically. If that's all the GP meant, then sure, I fully grok.

Most code executions vulnerabilities aren't remotely accessible, which this is, which makes priv-escalation particularly nasty. (eg: incorrectly assuming that since www-data user doesn't have access to anything sensitive, this bug isn't a big deal)

Is it remotely accessible on systems where sh is dash, though? That's specifically what was under discussion.

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

#148

Post by peterwwillis »

nknighthb wrote: post #19
Zweihander wrote: post #2

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…

Almost all vendor-supplied web interfaces that don't come bundled with a web server are CGI so you can just run it from whatever web server you have. Even some very popular 'appliances' out there that have their own web server run CGI.

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

#149

Post by [deleted] »

larrys wrote: post #143
tptacek wrote: post #128

Earlier quoted context omitted.

Any library anywhere in any application you run that calls out to bash that is called by any other library in that application, so long as that application is somehow hooked up to a web server, is potentially an unauthenticated GET request away from code execution; the exploit for this is potentially so simple that attackers can craft a single request, spider the Internet, and collect shells from applications you run…

So for example if you don't run web servers that are front facing on the internet (and you trust your (for example) intranet) then does this become an "asap" rather than a "drop everything"? "is potentially an unauthenticated GET request" Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?

[deleted]

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

#150

Post by sliverstorm »

JoshTriplett wrote: post #120

Is it just me, or are the patches "fixing" the vulnerability woefully insufficient? With the patch, bash stops executing the trailing code, but it still allows defining arbitrary shell functions from environment variables. So, even though the patch fixes the ability to exploit this via SSH_ORIGINAL_COMMAND or HTTP_*, anything that can set environment variables can still override an arbitrary command. (Note that privi…

The vulnerability was released, what, a few hours ago? With a major vulnerability, waiting around for a "proper" fix is probably not a good idea. Get in a hot-patch to minimize the damage, then work on a "proper" fix...
Post reply on HN