Date: Wed, 8 Oct 2014 15:48:10 -0700 From: Tim <tim-security@...tinelchicken.org> To: oss-security@...ts.openwall.com Subject: Re: Thoughts on Shellshock and beyond > I don't really want to get in the super-existential debate about code > vs data; I fully recognize that I'm gonna be in the minority on the > list, and maybe even in the wrong, but I just can't get too passionate > about this "best practice", having seen how few systems are (or can > be) designed with it in mind; and how little of a difference it makes > to them in the end. I don't want a big debate either. We're all busy. We work in security, afterall. > In a pragmatic sense, it's just that almost *everything* violates it. > The CPUs we use, the memory allocators we have running on them, all > the popular progamming languages and web frameworks. We still need to > secure these systems, rather than saying "oh well, you should have > done it differently from the start" =) Well, I guess, but the way you're interpreting this separation of code/data and the way that I am is clearly different. Which means we should perhaps refine how such a broad concept is stated. There are clearly cases where separation is practical, non-destructive, and beneficial for security. There are cases that are grey area. And there are cases where there's no way around mixing, because computation is computation. For the naive developer, how would you characterize this in a nutshell? > Sure. I'm not entirely convinced what the lessons are, though. I mean, > you expect the next big issue in OpenSSL or Apache. You can probably > even guess what it may be. You can maybe even make an intelligent > guess about the language features or coding patterns that will > contribute to it, or to learn from past bugs. With the bash bug... hm. To me, it's not about anticipating the next bug, it is about providing guidance to developers who care only so much about security so that we can avoid some bugs that we didn't anticipate. Best, tim PS- I'm of two minds on this. More recently I've decided that educating developers isn't nearly as effective as providing developers APIs and development environments that make it unlikely they will shoot themselves in the foot. It's not that developers can't be trained, it is that they will probably only be developers for a handful of years and move on to other roles later, with a whole new batch of green coders coming in to fill their positions. Anyway...
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.