Re: Thoughts on Shellshock and beyond

[Michal Zalewski <lcamtuf () coredump cx>]

> Well, I guess, but the way you're interpreting this separation of
> code/data and the way that I am is clearly different.
> There are clearly cases where separation is  practical,
> non-destructive, and beneficial for security.

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.

Or, in a slightly broader context: would a shell environment that
enforces strict and unconditional separation between any and all data
variables (even of the trusted kind - keep in mind that the author of
this code clearly assumed that the environment is trusted) and the
stuff that ever gets executed would be easy to construct, useful, or
would ever have a chance of gaining comparable popularity?

I think that instinctively shouting "code and data should be
separated" in this context, if we don't have good answers to these
questions, is just... well, kinda counter-productive =)

> To me, it's not about anticipating the next bug, it is about providing
> guidance to developers who care only so much about security so that we
> can avoid some bugs that we didn't anticipate.

Sure. So what specific implementation advice in the spirit of
"separate code and data" should have been provided for bash that would
have prevented a developer who assumed that the environment is trusted
from making this mistake, while still getting exports to work on
everything from Cygwin to AmigaOS?

/mz