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 16:42:43 +0200
From: Florian Weimer <fweimer@...hat.com>
To: oss-security@...ts.openwall.com, chet.ramey@...e.edu
Subject: Array importing in bash 4.3 (was: Re: Fwd: Non-upstream
 patches for bash)

> From: Florian Weimer <fweimer@...hat.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

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.