[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 30 Sep 2014 10:12:14 +0100
From: "Mark R Bannister" <mark@...seconsulting.co.uk>
To: oss-security@...ts.openwall.com
Subject: Re: Healing the bash fork
> > 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.
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
