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

[Alan Wild]

Yes, again... I was specifically working only with Red Hat patches.  I
hadn't actually seen Chet's patches anywhere (thanks for the link).
However, I was concerned that Red Hat was setting a major precedent and
effectively forking bash (arguably that is the case, but in a much more
minor way then I feared).

Red Hat's Linux is really the only widely used Linux distribution in our
company.  That said, my organization has special needs that requires us to
run multiple distributions and I wanted to make sure that these patches
weren't going to result in platform incompatibilities.

I also needed to understand whether we needed to "fight" our internal
pressures to install these patches or to request Red Hat to provide an
alternate fix.  I'm now (mostly) satisfied with the patches and I expect
we'll be installing them shortly.

As for your comment about "free support".... wasn't looking for Red Hat
support here.  I've independently reached out to Red Hat also, but I wanted
to understand how Red Hat's patches were different from chet's patches.  I
specifically wanted to Chet's solution (and directions with bash) to
understand whether they were in line with Red Hat.

-Alan

On Fri, Sep 26, 2014 at 4:11 PM, Eric Blake <eblake@redhat.com> wrote:

> On 09/26/2014 02:57 PM, Alan Wild wrote:
> > I want to apologize for adding more confusion to this issue.  My
> statements
> > about CVE-2014-7169 where incorrect and misguided.  This change does not
> > remove function exporting but only changes how the function names are
> > encoded as variable names.
>
> Actually, Chet's fix for CVE-2014-7169 (patch 26, mentioned here:
> http://www.openwall.com/lists/oss-security/2014/09/26/1) does NOT change
> how function names are encoded; that is a separate patch (such as this
> one that Red Hat is using:
> http://www.openwall.com/lists/oss-security/2014/09/25/13).  I'm hoping
> that Chet will accept the direction that Red Hat has already decided to
> go and issue patch 27 as a result, but that is still under discussion.
>
> But yes, it means that the market is now fragmented - upstream bash and
> Red Hat bash currently use DIFFERENT syntax for converting raw exports
> into functions.  Please read Red Hat's knowledge base article:
> https://access.redhat.com/articles/1200223
>
>
> > If it helps reduce the confusion, machines with the older bash releases
> or
> > CVE-2014-6271 would export a function as follows:
> >
> > -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f
> x;
> > env | egrep "functions still work"'
> > x=() {  echo "functions still work" "$@"
> > but after the patch you get
>
> By "the patch", you are here referring to Red Hat's patch, not Chet's.
>
> >
> > -bash-3.2$ bash -c 'x() { echo "functions still work" "$@"; }; export -f
> x;
> > env | egrep "functions still work"'
> > BASH_FUNC_x()=() {  echo "functions still work" "$@"
>
> Correct, this is symptomatic of a Red Hat build.
>
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>


-- 
alan@madllama.net http://humbleville.blogspot.com