Is this a problem even if /bin/sh is not bash? I'm pretty confused at why one would ever want /bin/sh to be bash (and not, say, dash). If you want bash, ask for it.
CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
131–140 of 226 posts
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#132My solaris is default to tcsh but with bash installed, am I affected?
Depends. Does any remotely accessible code anywhere on your system end up shelling out to bash explicitly?
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#133With the patched bash, if you run env X='() { (a)=>\' sh -c "echo date" This is equivalent to running date >echo That is, you can put something in the environment which causes it to drop the first token, run the result as a command, and redirect the result to the dropped first token. An example of a context where this would be exploitable, is a CGI webapp which accepts an uploaded zip file, stores it in a FAT filesys…
Just as an aside - is there a particular reason you specify the type of the filesystem? Is there something specific to FAT that might make this exploit viable? I'm thinking permissions, but I'm not sure.
I think it's that all files have mode 0777, i.e. executable by default. I think it can be changed with mount options though.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#134It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. Seriously, polutting ENV with HTTP headers? Admins should at least be able to block this. It should be possible to mitigate this attack (and many similar) by better header values parsing (in Apache/nginx/... - maybe in some proxy?). For instance, Content-Type header can only include alpha…
> It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. The web server side only comes into play for remote exploits. It is locally exploitable too (though the potential for useful exploits that way is lower, it is still a significant risk).
Care to elaborate? AFAIK this bug is about remote execution, not about privilege escalation. The reason is that the shell would be run with the same privileges as the user who is setting the ENV variables, and only privileged users should be able to set system-wide ENV vars.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#135Earlier quoted context omitted.
This assumes that system() is calling bash, but it usually calls /bin/sh, which is often linked to something other than bash (for example, dash is used on recent Ubuntu and Debian installs).
Yes but fixing that is a simple matter of replacing sh with /bin/bash.
You can only do that if you already have shell access (in which case the vulnerability gives you nothing). The remote exploit works because untrusted users can put code into an environment variable, but the target needs to create a new bash to execute the code.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#136Earlier quoted context omitted.
Just as an aside - is there a particular reason you specify the type of the filesystem? Is there something specific to FAT that might make this exploit viable? I'm thinking permissions, but I'm not sure.
I think it's that all files have mode 0777, i.e. executable by default. I think it can be changed with mount options though.
Thanks a lot, I was discussing this with a friend and we reached this conclusion too.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#137I've been trying to exploit our own systems which have PHP web frontends running under apache/mod_php, and in my testing PHP isn't passing through any HTTP_* environment variables at all in calls to system() or exec().
Even just echoing back the result of "env" it doesn't look like I get anything user-supplied whatsoever in there (no HTTP_*)
Can anyone more knowledgable confirm what I've seen?
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#138OK - 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.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#139Earlier quoted context omitted.
> It is curious to see how bash is mentioned everywhere, while the real culprit is the interaction between some web server and bash. The web server side only comes into play for remote exploits. It is locally exploitable too (though the potential for useful exploits that way is lower, it is still a significant risk).
Care to elaborate? AFAIK this bug is about remote execution, not about privilege escalation. The reason is that the shell would be run with the same privileges as the user who is setting the ENV variables, and only privileged users should be able to set system-wide ENV vars.
I can think of a few ways this could be a problem if you sudo. Sudo is configured to whitelist environment variables, so just figure out which ones are on the whitelist, or find half the people who have alised sudo='sudo -E'. From man sudo on OS X:
SECURITY NOTES
sudo tries to be safe when executing external commands. Variables that control how dynamic loading and binding is done can be used to subvert the program
that sudo runs. To combat this the LD_*, _RLD_*, SHLIB_PATH (HP-UX only), and LIBPATH (AIX only) environment variables are removed from the environment
passed on to all commands executed. sudo will also remove the IFS, CDPATH, ENV, BASH_ENV, KRB_CONF, KRBCONFDIR, KRBTKFILE, KRB5_CONFIG, LOCALDOMAIN,
RES_OPTIONS, HOSTALIASES, NLSPATH, PATH_LOCALE, TERMINFO, TERMINFO_DIRS and TERMPATH variables as they too can pose a threat. If the TERMCAP variable is
set and is a pathname, it too is ignored. Additionally, if the LC_* or LANGUAGE variables contain the / or % characters, they are ignored. Environment
variables with a value beginning with () are also removed as they could be interpreted as bash functions. If sudo has been compiled with SecurID support,
the VAR_ACE, USR_ACE and DLC_ACE variables are cleared as well. The list of environment variables that sudo clears is contained in the output of sudo -V
when run as root.
Re: CVE-2014-7169: Bash Fix Incomplete, Still Exploitable
#140Can 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.
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.