How not to find vulnerabilities (2)
Pete Lindstrom has argued that we need to end the bug-hunt:
Once evaluated, neither reason provides a good foundation for continuing the practice of vulnerability seeking, but it gets much worse when we consider the consequences.
There is a rarely mentioned upside to all this bugfinding, which is that researchers use the exploit code to test defensive mechanisms. Companies like Immunix, PivX, or Sana could not accurately test their tools without exploit code. That’s not an argument for immediate release. But those zoos of exploit code are very useful.
More importantly, Lindstrom says what we should not do. He’s clearly been talking to too many security experts. I’d like to hear what we should do. More laws like the DMCA? Privately paid bug bounties? Public beheadings?
I think that Lindstrom and I are in full agreement: The current system is bad, and we’d all like to do better. I don’t think attacking the bugfinders is the right approach. We need to stem the problem where it starts. The problem starts with development languages that are unsafe at any speed. Developers aren’t trained in their use. Projects are driven to ship quickly, without good QA.
There are better ways to develop? The eXtreme Programming folks call for better test harnesses. Better modularity allows you to develop and test patches faster. Better patch management, including bullet-proof rollback, allows your customers to deploy patches at lower risk. More use of things like Stackguard automatically close off venues of attack.
I recite these things because there are better ways to do things. Those better ways make sense, and smart companies are adapting them. I’d love to see an analogous way to improve bug-hunting.
[Update: Nudecybot has waaaaaaay too much time on his hands if he catches spelling errors like that. Must be the snow.]
My reply is here: http://spiresecurity.typepad.com/spire_security_viewpoint/2004/11/folly_of_vulner.html.
Sorry, still too new to the blog scene to have figured out trackbacks, etc.