Hacker News Reader

Comment by thebiglebrewski | Hacker News Reader

Wait, so can anyone tell me what the risk is if you don't apply this update?

I may be wrong here, but I'm pretty sure as long as you aren't running any network services, you are probably ok.

This is a big deal because it's remotely exploitable. But it's only exploitable remotely if you are running a network daemon that somehow invokes bash and sets environment variables without sanitization. Web sharing, SSH in some instances, a few MTAs.

The average user PROBABLY isn't running a daemon that is vulnerable. Though in some cases, you may be and not know it (like if you had turned on Web Sharing at some point)

All of this is not to say that if you can apply the patch, do it.

Yes and no. Bash gets used in many, often invisible, ways. Even a piece of compromised software run locally, or a web service accessing local data may present a problem. Admittedly this is a remote chance (and not in the wild afaik), but better safe than sorry. Patch took all of a minute to install. Let's hope it's actually a complete fix.

Yeah :/ That's the reason a lot of publications are calling this worse than heartbleed. Another problem is that it's up to individual users to fix - not just the people running servers.

This is a really good point. This could easily turn from something that is a remote exploit to some sort of OS independent malware/worm.

It's not a complete fix. This still returns 'not patched':

    foo='() { echo not patched; }' bash -c foo

Isn't it supposed to? Forbidding child bashes from inheriting exported functions would surely break quite a bit of code.

That could be fixed by this patch[0], which is not official and might break backward compatibility.

If you're facing an attacker with arbitrary control of both name and value of environment variables, and shell scripts that don't sanitize, you've got worse problems IMO.

Still, some Linux distributions are applying this unofficial patch, to only parse function definitions in prefixed environment variables to mitigate the threats.

[0] http://www.openwall.com/lists/oss-security/2014/09/25/13

The namespace change is an official patch now:

https://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-027

Ah, that seems a good way of going about it.

It's my understanding that the vector for end users would be DHCP in a coffee shop, but I could be wrong.

As others have mentioned, OSX is immune from the DHCP side.

Even then, at least the exploit for DHCP I saw manifests on the SERVER, not the client. When you are in a coffee shop, you are the client not the server. That means you would be the one to exploit the coffee shop, not the other way around.

Yes OSX is not vulnerable to the DHCP exploit.

No, the DHCP exploit was not on the server. It showed a sample payload a malicious DHCP could send to a client to achieve RCE. Also apparently some networks allow other clients to send DHCP commands so even if you trust the DHCP server it doesn't necessarily mean you are safe.

Ahh, yep. The POC was definitely from server to client, not the other way around. A huge concern for Linux laptops then.

at least until the `apt-get upgrade` or similar :)

As I read it before DHCP is implemented in the kernel in OS X and not glued together with bash scripts like in some cases in Linux.

I'm 99% sure that does not apply to OS X.

> I may be wrong here, but I'm pretty sure as long as you aren't running any network services, you are probably ok.

Would you say the same about Linux desktop users? Or do we tend to run Bash for more things? I'm unfamiliar with bash's role in OSX.

I don't use Linux, so I can't say for sure, but I've read that Linux DHCP cilents often call out to bash, so you should definitely upgrade if you ever connect your computer to untrusted networks (which you almost certainly do if it's a laptop and you're not paranoid)

You should upgrade regardless, though, since bash is so ubiquitous that it's hard to be sure you're not vulnerable in some esoteric way.

You are the only person who basically answered my question in a reply. Thanks!

Most likely nothing. You probably aren't running a web server that shells out to do CGI or something else. Macs don't use shell to do their network config. Those are the 2 biggies in the Linux world right now.

Basically to be vulnerable requires 2 components:

   1. You have to be able to get some remote user specified stuff into a environment variable.

   2. You have to invoke /bin/sh (calls to system(3)[1] do this, as well as actual shell scripts).

If you just have a non-server mac, there's no huge rush--no one has identified an actual stock service/daemon that is susceptible to the vulnerability.

[1] "man 3 system"

And what if my bash has been moved?

If your bash has been moved, then scripts which explicitly reference /bin/bash are going to have a bad time.

I see no downside to this.

Why on earth would you do such a thing?

Following instructions on Hacker News about immediately avoiding the issue while a patch was unavailable...

Apple's patch won't work for Yosemite, so I'm stuck there too.

Avoid bash vulnerabilities?

Unauthorized remote code execution. ... so pretty much worst case scenario

Its the Shellshock security vulnerability.

http://www.pcworld.com/article/2688672/two-scenarios-that-wo...

Reply on news.ycombinator.com