[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUCcR8FvPmqO5Y2YvOpNx83r-YcTy303DzN2FYiQ8kaSdA@mail.gmail.com>
Date: Mon, 29 Sep 2014 20:44:38 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: "Kobrin, Eric" <ekobrin@...mai.com>
Cc: "chet.ramey@...e.edu" <chet.ramey@...e.edu>, "dwheeler@...eeler.com" <dwheeler@...eeler.com>,
oss-security <oss-security@...ts.openwall.com>, solar <solar@...nwall.com>,
fweimer <fweimer@...hat.com>
Subject: Re: Healing the bash fork
> 1. Is it necessary that functions exported in one version of bash be
> imported into other versions?
>
> 2. Is it necessary for exported functions to be able to transition
> through other processes and back into bash, or is function export
> intended to support bash-invoked-from-bash only?
In general, I suspect that the "is it necessary" part is somewhat
moot. Very few things in bash are "necessary". But it's been there for
a long time and it's clear that a small fraction of users have come to
depend on the behavior.
If we need to break that existing code to eliminate the risk, so be
it; the feature is fairly obscure, so the damage will be limited.
But if the prefix approach works fine, and nobody can come up with any
compelling security-relevant reasons why it's a bad outcome... then
what's the point of breaking existing scripts?
I mean, all the arguments against the prefix approach boil down to
"but if the attacker can set arbitrarily named variables to arbitrary
values, then..." - and if that's something you allow across a security
boundary, you're almost certainly in trouble no matter what.
/mz
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.
