[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Array importing in bash 4.3 (was: Re: [oss-security] Fwd: Non-upstream patches fo
From:       "Kobrin, Eric" <ekobrin () akamai ! com>
Date:       2014-09-29 15:47:32
Message-ID: EED4C03C-C488-47B6-BDFC-FB054FC80585 () akamai ! com
[Download RAW message or body]

On Sep 29, 2014, at 10:42 AM, Florian Weimer <fweimer@redhat.com> wrote:

> > From: Florian Weimer <fweimer@redhat.com>
> > 
> > Note that if you ship 4.3, you might want to reevaluate a decision to
> > enable array variable import from the environment.
> 
> I changed the subject because I'm sure this parenthetical comment got lost.
> 
> Fortunately, in bash 4.3 (patchlevel 25), you cannot just -DARRAY_EXPORT 
> and get array variable import/export.  The code doesn't compile, and if 
> you fix that, it does not link, and if you fix that, well, you end up 
> with the following issue.  But I doubt anybody has done this, so it's 
> not a vulnerability (yet) and does not need CVE assignment etc.
> 
> The array import/export feature allows one to export and import 
> variables while preserving their array status.  Unfortunately, it 
> enables this:
> 
> $ env -i 'FOO=([$(echo broken > /dev/tty)]=a)' ./bash -c true
> broken
> ./bash: []=a: bad array subscript
> 
> As I said, it is currently not an issue, but it's probably best not to 
> enable this in the future at all, or use it with another form of mangling.
> 
> -- 
> Florian Weimer / Red Hat Product Security

This code also reveals a difference from the function export code.

The ARRAY_EXPORT code frees temp_string after using it. The function export code mallocs, but \
never frees it. That behavior predates the recent patches.

-- Eric Kobrin


[prev in list] [next in list] [prev in thread] [next in thread]