Re: CVE-2014-7169 vs CVE-2014-6271

[Eric Blake]

On 09/26/2014 10:58 AM, Alan Wild wrote:
> I've been searching for some clarification on these two "fixes" and I'm
> utterly confused.  I've been lead to believe RedHat's first patch (6271) is

[Red Hat is two words.]

> based on code from Chet that just causes bash to reject functions where
> code appears outside of the function body.

You are correct.  Patch 25 for 6271 stops the parser from reading
variables that contain more than a single function definition.  But it
does NOT stop the fact that the parser ran at all, so anything else
buggy in the parser is still triggered.  However, these subsequent bugs
are MUCH harder to turn into exploits; so if you have a choice between
patching 6271 now and waiting for the 7169 fix later at the cost of two
updates, vs. doing only a single update to both CVEs at once, I _highly_
recommend patching 6271 now because of how bad it is.

> 
> However, this patch was labeled as "insufficient" and 7169 now appears to
> completely remove the ability to receive function definitions from the
> environment.

Not quite true.  The proposed patch 26 for 7169 is here:

http://www.openwall.com/lists/oss-security/2014/09/26/1

and it does NOT prevent the import of function definitions.  All it does
is fix one (out of three) known parser bugs; the parser will STILL parse
the input, but will no longer misbehave because of that particular
parse.  I'm actually a bit more worried about CVE-2014-7186 being used
as a denial of service attack (it's a parser bug where it is fairly easy
to cause bash to segfault, and what I worry is that someone smart enough
can come up with a complex string that turns the segfault into an
arbitrary execution exploit - at least with CVE-2014-7169, the worst an
attacker can do is create a file, but not execute arbitrary code).

Furthermore, Red Hat's latest patch for 7169 does NOT prevent importing
of functions, it only changes the WAY in which functions are imported,
by sticking functions in a different namespace that no longer collides
with normal shell variables.  Remember, the vulnerability of 6271 is
that a user with the ability to inject arbitrary contents into an
ordinary shell variable has triggered arbitrary code; but if shell
functions no longer use ordinary shell variables, the user is now just
passing an odd string.  Here's Red Hat's patch:
http://www.openwall.com/lists/oss-security/2014/09/25/13

I'm hoping that Chet will take Red Hat's stance, or do something
similar, and post a patch 27 that keeps function imports, but by
implementing them in a way that no longer collides with normal variables.

> 
> I have production code that requires function exporting that's going to be
> broken by 7169.  Is this some knee-jerk reaction by just RedHat or is this
> a revised patch from Chet marking a change in bash functionality?

Again, the goal is to NOT break function importing.  Yes, we know that
right now there is a regression where function importing of functions
whose name is not a valid shell variable name is broken (see
https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00186.html), but
I'm hoping that Chet will resolve that regression in the near future.

> 
> My company's cybersecurity folks are pushing to install 7169 as soon as
> possible and while I'm trying to push back I need to know if this a
> strategic change in direction for bash, RHEL, or what, exactly.  (Because I
> need to know how extensively I need to reachitect my application).

If you have questions about RHEL in particular, I suggest asking your
contact at Red Hat rather than trying to get free advice on this list.
(Although my mail address is from redhat.com, I am only an interested
engineer, and NOT an official Red Hat policy maker).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature