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

41–50 of 432 posts

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

#41

Post by aroch »

agwa wrote: post #33
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

You appear to already have the updated package installed.

Last dist-upgrade was about a week ago, all indications point towards the bash released back in Jan 2013. It's fixed in 4.2+dfsg-0.1+deb7u1 and I'm running 4.2+dfsg-0.1

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

#42

Post by zobzu »

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

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

#43

Post by agwa »

aroch wrote: post #41
agwa wrote: post #33

Earlier quoted context omitted.

You appear to already have the updated package installed.

Last dist-upgrade was about a week ago, all indications point towards the bash released back in Jan 2013. It's fixed in 4.2+dfsg-0.1+deb7u1 and I'm running 4.2+dfsg-0.1

Well, that's very odd because that command reports vulnerable on an unpatched Debian system, but fails with exactly that error message on a patched system.

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

#44

Post by jtdowney »

ilconsigliere wrote: post #40

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

It is far worse in the sense that it can lead to remote code execution. However, the number of vulnerable sites is far far fewer. Like Heartblead this one will likely have a very long tail of systems remaining vulnerable. My guess is we will see this vulnerability used to compromise big targets in the next few months.

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

#45

Post by dllthomas »

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.

It's fixed in Debian as well.

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

#46

Post by Someone1234 »

dtech wrote: post #10
khaki54 wrote: post #6

So I took a great unix/linux systems programming class, http://sites.fas.harvard.edu/~lib215/ where you learn about all of the system software that you take for granted. Among other things, we had to write our own shell. There is an awful lot to consider, and most of it you are just trying to get to work properly. With regard to security, you feel like you are protected for the most part because the shell resides in…

It allows arbitrary code execution if an attacker can modify environment variables through other software. Most webservers put certain HTTP headers in environment variables. I can certainly see the how this could be exploited.

> Most webservers put certain HTTP headers in environment variables.

I legitimately don't understand why they might do such a thing. Can you explain?

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

#47

Post by revelation »

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

GitHub? I'm reminded of

https://gist.github.com/joernchen/a7c031b6b8df5d5d0b61

Of course that was fixed a long time ago, but I wonder what other systems are just a thin veneer over pretending the user controls a shell.

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

#48

Post by lmz »

ars wrote: post #32
huhtenberg wrote: post #22

Earlier quoted context omitted.

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

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

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

#49

Post by dllthomas »

korzun wrote: post #34
agwa wrote: post #17

It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by default, since /bin/sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time. Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.

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.

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

#50

Post by fromtheoutside »

dpeck wrote: post #13
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?

you're just paying attention. There have been some interesting ones the last year or two but this is really a trickle compared to early through mid 2000s

I still remember Redhat 6.2. Most remote exploits in a distribution ever.
Post reply on HN