oss-sec mailing list archives
Re: Healing the bash fork
From: "Mark R Bannister" <mark () proseconsulting co uk>
Date: Tue, 30 Sep 2014 10:12:14 +0100
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.
Current thread:
- Re: Healing the bash fork Mark R Bannister (Sep 30)
- <Possible follow-ups>
- Re: Healing the bash fork Sven Kieske (Sep 30)
- Re: Healing the bash fork Mark R Bannister (Sep 30)
- Re: Healing the bash fork Sebastian Krahmer (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Healing the bash fork Sebastian Krahmer (Sep 30)
- Re: Healing the bash fork John Haxby (Sep 30)
- Re: Healing the bash fork Ed Prevost (Sep 30)
- Re: Healing the bash fork Rich Felker (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Healing the bash fork Michal Zalewski (Sep 30)
- Re: Healing the bash fork Simon McVittie (Sep 30)