Hi everyone,
We just published this tool to test for Shellsheck. https://suite.websecurify.com/market/shellshock
Do a scan over before it is too late.
CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
151–160 of 226 posts
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#152Ubuntu Trusty's patched version 4.3 doesn't seem to be affected by this, but Precise version still is (4.2; same one as in Debian).
Is this new exploit version dependent?
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#153OK - so assuming that there isn't going to be a single patch which fixes all possible / related bugs any time soon. Options? - Change /bin/sh to something else. (CentOS has BASH as default, alas...) - Filter out unknown, or suspicious looking HTTP vars / env vars at varnish/apache/nginx level, somehow... (doesn't stop other services) - Figure out some clever SELinux configuration that blocks it. I wonder how much wou…
I just followed the following instructions on Arch for replacing bash with dash: https://wiki.archlinux.org/index.php/Dash The technique is applicable to other distributions as well. Note: on my Arch install the checks showed there were no scripts relying on /bin/sh being bash. Edit: direct link to checkbashisms.pl - http://anonscm.debian.org/cgit/collab-maint/devscripts.git/p...
You want to actually remove bash god forbid something calls /bin/bash directly instead of using the /bin/sh link.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#154lol @ this: http://seclists.org/oss-sec/2014/q3/681
Soon someone will be suggesting that you have to add some random string to all of your env variables to make them work, otherwise they are ignored, like with CSRF mitigation.
Actually, I jest, but that's probably a good idea, anything running on the system could view some /tmp file with the string and append it to the env variable string or something, but any remote client wouldn't be able to access that.
Hmm...
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#155Earlier quoted context omitted.
It's so you can export a function into child shells: http://stackoverflow.com/questions/1885871/exporting-a-funct... Hardly worth the security cost in retrospect, but some bash scripts will surely break if it were just ripped out.
Seems like something that should be turned off by default and enabled when desired/needed.
I was thinking the same thing – if there ever was a case for a "bash --allow-terribly-insecure-features" flag this is it.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#156Reproduced from my comment on the discussion of the previous CVE The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)= Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.
The reponse from ubuntu 14.04
user@user:~/ X X: user not authorized to run the X server, aborting.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#157[deleted]
If it's truely unused, you should be using /bin/false instead of /bin/sh. Note that /bin/sh is not always dash in many cases, so just because you are using /bin/sh over /bin/bash doesn't mean you're not vulnerable.
/bin/nologin exists for this reason - if nothing's supposed to be logging in as that user, surely you want a log of when someone tries!
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#158Reproduced from my comment on the discussion of the previous CVE The same trick can be used to read files as well $ date -u > file1 $ env -i X='() { (a)= Though obviously it's going to be trickier to find an system that issues commands in a way that can act as a path for that sort of exploit.
The reponse from ubuntu 14.04 user@user:~/ X X: user not authorized to run the X server, aborting.
[deleted]
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#159Can someone explain why bash is evaluating and looking for function definitions in every environment variable? What would be broken if this entire "feature", whatever it is, was completely disabled? That's almost like a C compiler looking for C programs in string literals. It just doesn't make sense to me.
Don't use bash as a system or scripting shell then - thats exactly why dash, or the BSD shells exist. Exporting functions makes no real sense anyway, at least if you did it by hand it would be obvious how dangerous it is.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#160OK - so assuming that there isn't going to be a single patch which fixes all possible / related bugs any time soon. Options? - Change /bin/sh to something else. (CentOS has BASH as default, alas...) - Filter out unknown, or suspicious looking HTTP vars / env vars at varnish/apache/nginx level, somehow... (doesn't stop other services) - Figure out some clever SELinux configuration that blocks it. I wonder how much wou…
I wonder how much would fail on switching out BASH as default sh? Ubuntu did that years ago, to speed up booting.
Yes, and in doing so they (well, Debian) upstreamed a lot of fixes for bashisms, so most system stuff is ok.
Apparently a lot of node.js stuff uses #!/bin/bash explicitly in scripts, so removing bash entirely might be difficult if you use node, or otehr stuff.