On 09/25/2014 01:15 PM, Linda Walsh wrote:
> Eric Blake wrote:
>> And _that's_ what I want changed, by proposing that bash use 'f()=...'
>> rather than 'f=() {...' as the magic it uses for exporting functions
>> from parent to child.
>>
> ---
> That could still be put in the environment (though not as easily w/o
> special code).
Where I'm coming from is that in portable shell programming, you _can't_
assign a value to f()=... (yes, 'env' can be used to pass non-shell
variables, but that is already non-portable). The fact that portable
programs are now slammed with the notion that some values cannot be
portably assigned to a variable is what gets avoided by not using
portable variable names as the mechanism for passing function
definitions between parent and child.
>
> Not that it is any more secure but how about replacing '()' with
> 'ƒ(8-byte-hex-sig)'
> that is some crypto-sig of the function? If it matches the function's
> sig, then function
> would be read in. Of course like any crypto function, it's crackable,
> but to toss
> in enough bits to really forestall that, would be prohibitive unless
> done on a
> whole 'block' of imported info, i.e.
Overkill. The security hole arises because the problem, as it currently
exists, is triggerable by ANY portable environment variable definition.
It is very easy to trick programs, particularly programs running on
other machines or with elevated privileges into defining a normal shell
variable environment variable of ANY name, and when that variable then
gets eval'd and triggers any bug in the bash parser, the attacker has
gained control. As soon as you've made function passing require
something that can't be used as a normal shell variable, you don't have
to go any further. Portable programs now no longer have to vet what
they store into regular variable names, and scrubbing an environment for
non-shell names is also fairly easy.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
