[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54296FE3.6030903@redhat.com>
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.
