[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Sep 2014 17:24:11 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com, Tavis Ormandy <taviso@...xchg8b.com>
CC: chet.ramey@...e.edu, Michal Zalewski <lcamtuf@...edump.cx>,
Solar Designer <solar@...nwall.com>, Eric Blake <eblake@...hat.com>
Subject: Healing the bash fork (was: Re: CVE-2014-6271: remote
code execution through bash)
On 09/28/2014 03:39 AM, Chet Ramey wrote:
> OK, here are the more-or-less final versions of the patches for bash-2.05b
> through bash-4.3. I made two changes from earlier today: the function
> export suffix is now `%%', which is not part of a the set of valid variable
> name characters but avoids any potential problems with including
> shell metacharacters in the name; and this version refuses to import shell
> functions whose name contains a slash, for reasons I discussed earlier.
Chet, thanks for posting an official version of the prefix/suffix patch.
I looked at how the “%%” encoding works with Debian's “at” (which is
also used by Fedora and downstreams). Unfortunately, it does not
address the issue, “at” still prints error messages, both with dash as
/bin/sh and bash. As a result, I wonder if a suffix which is actually
within the shell variable syntax wouldn't be a better choice (e.g.,
three randomly chosen alphanumerics), as that would make the “at”
environment serialization code work again. (I'm not concerned about
“at” specifically, we'll change it anyway, it's about similar code out
there which we don't know about it yet.)
Eric, does “%%” even work for Cygwin, or does it cause strange effects
there? (For the Windows shell, “%” is the variable starter character, a
bit like “$” in sh-type shells.)
Related to that is that we should try to converge back to uniform bash
behavior across distributions. Right now, the majority seems to use
“()” as the suffix (which is problematic, per the above), and they also
reject characters such as “.:-” in import function names (a restriction
which was inherited from the first patch which only tried to block
command execution). The latest upstream patch uses “%%”, and allows
anything allowed in a regular function definition, except absolute
pathnames.
I'm not sure how to move towards a common solution. I think avoiding
non-serializable environments could be a compelling reason to switch the
suffix, but “%%” does not provide that.
(From a security POV, *requiring* that imported functions contain at
least one special character would actually be best, but obviously,
that's not backwards-compatible.)
--
Florian Weimer / Red Hat Product Security
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.
