[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUA=uwij3Z8Wa0Xj4YenAFCVzLpSD7+xaXDOcQg91OaeLA@mail.gmail.com>
Date: Wed, 8 Oct 2014 17:30:41 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Thoughts on Shellshock and beyond
>> 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
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.
