Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ