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.