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

181–190 of 432 posts

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

#181

Post by dllthomas »

agwa wrote: post #177
dllthomas wrote: post #147

Earlier quoted context omitted.

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

Yes, potentially - if at any point during the execution of a program (or its descendents) a bash script gets called with an untrusted environment variable value from a remote source. The difference between a system with bash as /bin/sh and a system with dash as /bin/sh is that the bash system is implicitly executing bash all the time, whereas the dash system requires an explicitly-bash script to be executed. So the d…

Well, sure. It seems a slightly odd way to phrase it if that's the entirety of what korzun meant, though. Is there somewhere that happens in a typical out-of-the-box Debian or Ubuntu box?

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

#182

Post by traviscj »

teach wrote: post #161
pjungwir wrote: post #138

Earlier quoted context omitted.

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!

Just did an update on my Linode and one of the updates was replace bash 4.1-2ubuntu3 So seems like it's there now.

Depends on whether you have mirrors.linode.com or the ubuntu servers set up in sources.list. I had to swap mine out.

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

#183

Post by increment_i »

notacoward wrote: post #174
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…

It's not just you. The fact that an environment variable can override e.g. "git" to do something else is a real problem requiring separate protection. However, that's effectively PATH injection rather than code injection so it's already addressed in many cases.

I might be misunderstanding this, but this can be accomplished through http request headers?

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

#184

Post by kazinator »

ars wrote: post #118
agwa wrote: post #100

Earlier quoted context omitted.

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

It has not reached the lts mirrors yet, but you can get it from http://incoming.debian.org/debian-buildd/pool/main/b/bash/

Thanks. dpkg --install'ed the amd64 .deb package, and the vulnerability test passes now.

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

#185

Post by justincormack »

peterwwillis wrote: post #142
vidarh wrote: post #57

Earlier quoted context omitted.

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…

Fortunately they are unlikely to install bash at all on a router.

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

#186

Post by actionscripted »

fluidcruft wrote: post #122
_b8r0 wrote: post #60

My OSX Mavericks install appears to be affected: foom:~ steve$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" vulnerable this is a test

Doesn't OSX ship the 8-year-old bash 3.2 (2006) i.e. the last version available as GPLv2? (Apple hates GPLv3)

For me in 10.9.5:

  $ bash --version
  GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
  Copyright (C) 2007 Free Software Foundation, Inc.

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

#187

Post by kazinator »

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

Even if the malicious code doesn't have superuser context, it can do damage to whatever context it is running under. If it's running as www-data, it can trash all your www-data-owned files. Or send your www-data-owned password files somewhere, etc. Unprivileged code can also attack other systems (firewalls permitting); you don't have to be root on system A, to be part of a bot net which attacks system B. Denial-of-service havok can be wreaked from a regular user context, too. Not to mention privacy violations. Pretty much all browser-related security and privacy issues are user space!

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

#188

Post by steveklabnik »

teach wrote: post #161
pjungwir wrote: post #138

Earlier quoted context omitted.

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!

Just did an update on my Linode and one of the updates was replace bash 4.1-2ubuntu3 So seems like it's there now.

https://launchpad.net/ubuntu/+source/bash/4.3-7ubuntu1.1 seems to be at least one version of the fix, I'm unsure about LTS and other releases.

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

#189

Post by isivaxa »

nandhp wrote: post #129
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…

Because this allows execution of arbitrary commands from any unsantized environment variable. Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string. GET / HTTP/1.0 User-Agent: () { :; }; rm -rf / Restricted SSH accounts (like the ones used by GitHu…

"A CGI script written in bash"

You're killin' me here. If you expose a shell script directly to the network, you're exposing a shell and deserve to be pwned.

Post reply on HN