Date: Tue, 7 Oct 2014 21:06:14 -0700 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <oss-security@...ts.openwall.com>, "David A. Wheeler" <dwheeler@...eeler.com> Subject: Re: Thoughts on Shellshock and beyond I feel that to some extent, "separation of code and data" is an overused, overly simplistic, and arbitrarily applied mantra; it is also the antithesis of interpreted scripting (and a good chunk of other stuff in computing), for mostly valid reasons. Heck, did you know that web fonts loaded and displayed by your browser come with an embedded hinting bytecode that gets executed in a miniature VM? And while this is kind of crazy, it's there because... well, there aren't that many sane alternatives. (Some 15 years ago, I would have given you a different answer - I even had a pet project of a brand new operating system that would solve all of world's ills. Today, I sort of accept that we're stuck with Unix and that there's plenty of usability-security trade-offs that exist for a reason, not just because other people are clueless ;-). If I really had to pinpoint the causes (and that feels a bit like a function-fitting exercise), I'd say that four things went maybe-kinda-preventably wrong: 1) The feature was clearly added with no basic consideration for the possibility of ever seeing untrusted data in the value of an environmental variable. This lack of a threat model seems to be the core issue, essentially precluding the discussion of potential "best practices" such as namespaces, magical out-of-band function passing, etc. Ideally, post Morris worm, this assumption should have raised some eyebrows. On the flip side, the code predated much of the modern infosec practice, and it's unlikely that any security engineers monitor bash development even today - so while it's easy to prescribe solutions in retrospect, not sure how credible they can be... 2) The mechanism wasn't well-documented *and* just as importantly, has fallen into near complete obscurity, largely precluding security researchers from bumping into it by accident. The "not falling into obscurity" part is not solvable, although it's a pattern that also haunts the browser world, and may be an argument for aggressively sunsetting features that do not catch on - something currently not mentioned on your list. The detailed documentation part is perhaps easier to tackle. The security properties of shells are generally under-documented and counterintuitivie, as evidenced in some of the followup discussions where somebody was showing off a "safe" use of system() supposedly rendered unsafe by Florian's patch. Decent security-centric docs, authored or even merely just reviewed by the maintainers, would have helped highlight the risk. 3) Apparently, for 20+ years, nobody in the security community has ever read a book on shell programming that mentioned this feature, and has never ventured deep enough into the man page, to have a "hmm, I wonder how that works" moment when seeing a vague mention of the feature. I don't think that's easily fixable; as mentioned earlier, you sort of start with certain assumptions on what may be a good use of your time, and a behavior like this would be completely off the radar. You wouldn't reasonably expect /bin/uname to phone home to a server in Russia, so you don't check manually and it probably doesn't cross your mind to create some sort of an automated validation model that verifies the same. The infosec community is small, and there's plenty of bugs to find, so we have to prioritize pretty heavily. 4) Following the original find but before the end of the embargo, there was no immediate realization that the underlying parser is complex and likely not designed with security in mind, and therefore, that it will very likely follow a well-established pattern and come apart under closer scrutiny. I'm not sure if this is an argument for not having embargoes (perhaps) or for sanctioning more thoughtful reviews of the proposed fixes. Or perhaps it's just a fluke. /mz On Tue, Oct 7, 2014 at 7:47 PM, David A. Wheeler <dwheeler@...eeler.com> wrote: > All: > > Given the feedback here and elsewhere, I've tried to distill how to detect or prevent shellshock-like things ahead-of-time. My current try is here: > > http://www.dwheeler.com/essays/shellshock.html#detect-or-prevent > > More ideas and refinements would be welcome. I've also made a number of refinements (e.g., the timeline has more info, where the name came from has been identified, etc.). > > Thanks again! > > --- David A.Wheeler >
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ