|
Date: Wed, 8 Oct 2014 21:47:24 -0700 From: Tim <tim-security@...tinelchicken.org> To: oss-security@...ts.openwall.com Subject: Re: Thoughts on Shellshock and beyond > > I think you're taking on a too rigid mindset here. > > Well, I just honestly don't understand how adding the prefix to > environment variable fits in the mold of the rule you cite ("When an > existing construct in a system is widely expected to be used for > storing data, avoid overloading it for use of storing code"). It > strikes me as the epitome of overloaded, in-band transmission of code > alongside with data - pretty close to the menace of HTML + JS, just > done in a slightly smarter way. What I was trying to do was work with you to refine that statement to make it more clear to both you and me and hopefully as solid advice for developers. That quote above wasn't the final draft. But it seems like you're a little too fixated right now on the specific vulnerability at hand. Yes, of course designating a single environment namespace or single environment variable for exports is a kind of overloading. But at least it is distinguishable, if a tad hacky feeling. Before the fix, there was no reasonable way to distinguish because any variable could have code or data. This is very much analogous to putting code in memory. You can put either instructions or data in memory, but these days we designate certain chunks of it as code and mark it read-only, with data non-executable. But it's all data. In the case of HTML + JS, it would be easier to defend against XSS if JS were only included through <link>-like tag in the <head>. The scripts could use the DOM to register event handlers and whatever else throughout the document. In this situation, would JS technically embedded in part of the HTML? Sure, it is there in the head block and could be tampered with if an attacker could inject a <head> tag. But it is a lot easier for developers to exclude that possibility, rather than worry about crazy things like &{...}; (remember that one?). Would JavaScript have caught on as quickly as it did if it were done that way from the beginning? Who the hell knows. I think it might have, just because there weren't other options, at least for a short time. > If what Florian has implemented embodies the spirit of the rule we're > preaching here, I'm all for it, but not sure if most developers would > interpret it this way. A natural interpretation would be, "don't put > functions in the environment", which is fine, except that there aren't > many other places to put them if you really want to implement exports > in the first place. Yes, I believe what Florian put forth does embody the spririt of the rule. Would I like the separation to be stronger? Yes. But in practice, it is probably difficult with all of the constraints. You guys have looked at that far more closely than I have. But I don't believe we need to restrict any rule of thumb to environment variables. Most developers don't even "get" environment variables these days, so it's not particularly helpful to a broad audience. 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.