Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.