Hacker News new | past | comments | ask | show | jobs | submit login

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!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: