[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Oct 2014 17:54:17 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
> > 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.
I think you're taking on a too rigid mindset here. Taking the
phrasing too literally.
All code *is* data. Machine code is bytes in memory, which is data.
Therefore code is a subset of data. No matter where you put it, it's
mixed in that highly abstract sense. In hardware architectures we
designate certain pieces of memory to store code and others to store
things that aren't instructions. This is fine. It is mostly well
defined and people have reasonable expectations about this
designation. Same thing with environment variables that have
designated purposes/namespaces/whatever. The problem comes about when
you have no designation and no expectation of which is which.
tim
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.
