Hacker News Reader

Comment by tonteldoos | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com