Security Management Strategies for the CIOControversy surrounds researcher Mike Lynn's decision to present details on the Cisco IOS flaw, but where would we be without such disclosure?
In his column, "Black Hat researcher Lynn no hero to global security,"
Requires Free Membership to View
Ira Winkler takes the position that detailed vulnerability information should not be released to the general public because it causes more harm than good. He asserts that bad guys will use the information to write exploits and worms, while the only good coming from the disclosure is that people will know that they need to patch. However, there is actually little harm in releasing details once people have had time to patch and sharing vulnerability knowledge substantially benefits the future security of our infrastructure.
I will admit that more information makes the worm or exploit writer's task easier. More information will generally cause malicious code to be written more quickly. But the lack of detailed information does not preclude the generation of an exploit. This has been true for years, but recent developments in the binary differential analysis of vendor patches make the point moot. Binary differential analysis is a reverse engineering technique that lets an exploit writer inspect a vendor's patch on day one of release and understand the exact details of the vulnerability.
Recently, Halvar Flake, the creator of BinDiff, posted a message to a security mailing list detailing how he
 |
||||
|
|
|||
|
||||
Winkler's harm vs. good calculus left out a substantial part on the good side of the equation: the advancement of secure software development techniques. Secure software development requires in-depth knowledge of all classes of vulnerabilities and their potential exploitability. Why would anyone want to impede this? Consider the fact that a newly discovered vulnerability may introduce a new class of security issue. At one time format string vulnerabilities, cross-site scripting and integer overflows were new. Someone had to discover the first one and when they did they may not have even known it was a new class of vulnerability. Without publishing the details, a new class of vulnerability will never be widely known and development teams or their security contractors will not know to look for them as software is built. The same is true for new exploit techniques. If they aren't widely known, software development teams will prioritize issues as non-exploitable, no need to fix. People don't dedicate expensive development resources to fix classes of security bugs that are merely theoretically exploitable.
If Winkler's vulnerability detail secrecy took hold back in 1995, today we wouldn't know to audit for format string vulnerabilities, cross-site scripting problems or integer overflows in software during its development. All Windows heap overruns would be downgraded to unexploitable, no need to patch. This head in the sand approach would cause our software infrastructure to be far more brittle than it is now.
Once a vendor patch has been available for 30 days and people have had ample time
|
||||
|
|
|||
|
||||
About the author
Chris Wysopal is a founder of the Organization for Internet Safety, an industry group that has published guidelines for responsible vulnerability disclosure. As vice president of research and development for security consultancy @stake, he provided expert testimony before Congress on the subject of vulnerability research.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation