Re: Healing the bash fork

["Mark R Bannister" <mark () proseconsulting co uk>]

> > 1. Is it necessary that functions exported in one version of bash be
> >    imported into other versions?
> >
> > 2. Is it necessary for exported functions to be able to transition
> >    through other processes and back into bash, or is function export
> >    intended to support bash-invoked-from-bash only?
>
> In general, I suspect that the "is it necessary" part is somewhat
> moot. Very few things in bash are "necessary". But it's been there for
> a long time and it's clear that a small fraction of users have come to
> depend on the behavior.
>
> If we need to break that existing code to eliminate the risk, so be
> it; the feature is fairly obscure, so the damage will be limited.
>
> But if the prefix approach works fine, and nobody can come up with any
> compelling security-relevant reasons why it's a bad outcome... then
> what's the point of breaking existing scripts?
>
> I mean, all the arguments against the prefix approach boil down to
> "but if the attacker can set arbitrarily named variables to arbitrary
> values, then..." - and if that's something you allow across a security
> boundary, you're almost certainly in trouble no matter what.

Florian's prefix/suffix patch is not going to protect against the setuid/setgid exploit that I reported to this list 
last week.

In fact, it only guarantees isolation from the Apache web server attack vector, but provides no guarantees from 
anything else we have not yet discovered that accepts arbitrarily named environment vairiables (I wonder what 
CVE-2014-6278 is all about, no technical details made public yet ...).


Note that once someone has worked into your networks through unpatched front-end Apache web servers (or as yet 
undiscovered exploits via Sendmail or Qmail for example), the first thing a keen attacker is going to do is scan for 
opportunities to use the setuid exploit.


There may also be daemons running out there that have different ways of setting environment variables that match the 
prefix/suffix pattern.  It's hard to audit in a large enterprise.  One possible way to begin auditing this is to check 
accounting logs for the use of bash by non-interactive user accounts, but even then I'm sure the list will be as long 
as your arm and still a mountain of work to assess.


I discuss the setuid/setgid vulnerability at the following site, including demonstrating how Florian's prefix/suffix 
patch provides no protection:


http://technicalprose.blogspot.co.uk/2014/09/shellshock-bug-third-vulnerability.html.


We really do need an official patch that allows us to switch function exports off on a server, a setting which cannot 
be overridden by the user.