|
Message-ID: <CALx_OUAAO5sOs2iZ1cXbvZiKkz8ektkNDcaYenGD=hr-=-AMtQ@mail.gmail.com> Date: Wed, 8 Oct 2014 13:50:17 -0700 From: Michal Zalewski <lcamtuf@...edump.cx> To: oss-security <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. 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" =) > It was certainly hard for the original developer to anticipate how > this would become a problem, given the time and place. But I think we > can try to learn from this and similar issues and hopefully make fewer > of these mistakes in the future. 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. > So yes, documentation is important for setting expectations. But no > one reads the manual, either. It's not necessarily about every user reading the doc; just about making sure that at least the infosec community understands the exposure, which would mean that problems could be audited for, workarounds could be implemented, or semantics changed. I have no doubt that if the () { thing was mentioned in README.security, it would not have taken 20+ years to spot the bug. Cheers, /mz
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.