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.