Re: Thoughts on Shellshock and beyond

[Michal Zalewski <lcamtuf () coredump cx>]

> > Well, in the specific context of bash, where it's being singled out as
> > a major contributing factor to the bug: how would you establish an
> > out-of-band channel for exporting functions that keeps them separate
> > from "pure" data? As far as I can tell, there is no trivial and
> > portable way.
>
> Well, I think we can all think of a few options, some more portable
> than others.  The current namespace change is one option, obviously,

But that's not really separating code and data, right? It doesn't feel
like it follows the spirit of this phrasing:

"When an existing construct in a system is widely expected to be used
for storing data, avoid overloading it for use of storing code."

...because it very much overloads the syntax to store code alongside
with the data, in a way that theoretically shouldn't but in practice
may collide. It's not a whole lot better than the "separation" of CSS
and JS in HTML, in the sense that both of them are sort of guarded by
delineated by specific syntax structures.

> 1) A single dedicated environment variable for all function exports.
> e.g.:

Ditto?

> 2) A bash-specific file handle.  Before forking, bash sets up a pipe
> to share with it's child.

What it's the 'exec' built-in, and the parent shell terminates before
the new one gets a chance to run?

What if control passes through an intermediate program that isn't bash?

Cheers,
/mz