[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141007152351.GS3267@sentinelchicken.org>
Date: Tue, 7 Oct 2014 08:23:51 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Cc: Hanno Böck <hanno@...eck.de>
Subject: Re: Thoughts on Shellshock and beyond
> > What class of bug is Shellshock? "Weird feature invented in
> pre-Internet era"? How do you conquer this class of bugs?
>
> I am still struggling with this one. I am trying to create that list here:
> http://www.dwheeler.com/essays/shellshock.html#detect-or-prevent
>
> But to be honest, that list is pretty pathetic. This is a challenging class of vulnerability to detect or prevent ahead of time. Ideas would be very welcome.
I wouldn't go so far as to say shellshock has a well-defined "class"
of vulnerability or bucket that we can stick it in, but it does
violate one of my own personal (and I think, the most important)
_principles_ of secure software design: don't mix code and data.
What do I mean by that? Concrete examples of failures:
* word docs with macros
* document markup with embedded script (yes: HTML/JS)
* OGNL expressions in Struts URL parameters
Any time you design a system to accept executable code as well as data
in the same format/context/whatever, you invite a huge number of
possible attacks. These attacks may not manifest themselves
immediately or obviously. It may require a change in the way the
software is used, or implementation bugs to expose the risk, but it
is a highly risky design approach.
People expect office documents to be data, but in fact they can
include a limited form of code as well. In the case of word docs and
macros, the risk was exposed by implementation bugs and the difficulty
of keeping the language sandboxed.
In the case of HTML/JS, the risk came from the way JS is embedded
inline in so many locations people can't safely allow HTML (a data
markup format) without allowing JS as well. (If JS were only allowed
as external resources and not as, say, events embedded in attributes,
it would be less mixed and easier to make safe).
In Apache Struts, OGNL is used are used to parse the entire POST body,
variable names and values. However, OGNL expressions are executable
code, which breaks the whole assumption that POST variables are data.
So the Struts team is now playing whack-a-mole with blacklist blocking
of specific attack vectors.
In the case of shellshock, the "mixing" of code and data came about
because environment variables, normally used to carry data, were
overloaded and used to carry code. This is very similar to the Struts
case.
David: your item "Create namespaces where practicable" is effectively
an implementation of what I'm talking about here. By creating
namespaces, you're creating a partition between code and data. But
the underlying principle is just to keep these two things separate and
*well defined* as separate via whatever mechanism makes the most sense.
Cheers,
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.
