Hacker News Reader

Comment by k_roy | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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

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.

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

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

Reply on news.ycombinator.com