Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Sep 2014 10:47:32 -0500
From: "Kobrin, Eric" <>
To: "" <>
CC: "" <>, Florian Weimer
Subject: Re: Array importing in bash 4.3 (was: Re:
 Fwd: Non-upstream patches for bash)

On Sep 29, 2014, at 10:42 AM, Florian Weimer <> wrote:

>> From: Florian Weimer <>
>> 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

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.