4 ms·
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
by tonteldoos 12y ago
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.
- k_roy 12y agoThis is a really good point. This could easily turn from something that is a remote exploit to some sort of OS independent malware/worm.
- tonteldoos 12y agoYeah :/ 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.
- bashinator 12y agoIt's not a complete fix. This still returns 'not patched': foo='() { echo not patched; }' bash -c foo
- dllthomas 12y agoIsn't it supposed to? Forbidding child bashes from inheriting exported functions would surely break quite a bit of code.
- scintill76 12y agoThat 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 http://www.openwall.com/lists/oss-security/2014/09/25/13