http://www.theregister.co.uk/content/55/29195.html By John Leyden Posted: 05/02/2003 The UK security expert who discovered the flaw which was exploited by the Slammer worm has concluded it does more good than harm to publish proof of concept code. In a posting to BugTraq, David Litchfield of NGSSoftware expressed concerns that his proof of concept code was used as a template by unknown vandals in creating the destructive Slammer worm. The Slammer Worm uses SQL Server Resolution service buffer overflow flaw, discovered by NGSSoftware, and patched by MS last July. In August last year, Litchfield made a presentation on the issue at the Black Hat conference in Las Vegas that featured a demonstration of proof of concept code. At the time, Litchfield warned of the DDoS potential of the flaw and urged admins to patch their systems. The following month, NGSSoftware published a white paper on auditing SQL Server which contained an explanation of its proof of concept code. Was this helpful to the unknown criminal or criminals who created Slammer? Litchfield thinks the information only helped save time in writing the code. The virus authors were skilled and were quite capable of writing Slammer even without NGSSoftware's work to build on, he reckons. "Whoever authored the worm knew how to write buffer overflow exploits and would have been capable of doing this without using my shellcode as a template," Litchfield writes. "Having access to my code probably saved them around 20 or so minutes - but they still would have been able to do it without mine". Access all areas The chaos which unfolded last weekend after the release of the Slammer worm has re-ignited the debate on full disclosure of security vulnerabilities. It has also prompted Litchfield into a bout of soul-searching. But he still concludes that the publication of proof of concept code has a beneficial role to play in Internet security. So NGSSoftware will continue to provide full disclosure on the security issues it unearths, he told us. Here is Litchfield's explanation for this decision: After careful consideration I've decided that the publication of proof of concept code does have an important and beneficial role to play in Internet security. This decision was not made lightly and has been influenced by conversations with my colleagues at NGSSoftware, friends and peers in the industry and the many mails I received in response to my original mail to the Securityfocus Bugtraq list. As far as those responses go not a single one suggested that I, or NGSSoftware, cease to provide proof of concept code for the vulnerabilities we find and most gave salient reasons as to why we should continue to do so. This message is to explain why NGSSoftware will continue with full disclosure of issues. The threats and risks Internet connected systems are exposed to are well known. Connect an unpatched system to the Internet and it will be compromised by a worm or hacker within minutes. There are people out there with high levels of intelligence developing, sharing and actively using exploits against such systems. Some do it for the fun of it, others as they see it as a challenge and still others who try to gain from it - whether financially or through peer recognition. Regardless of motive, there is much to be learnt from these people and their exploits. But if this was the only source of information for those working in the security industry then the "bad guys" would always be one step ahead of the "good guys"; and if they're one step ahead we lose and so do the organizations we're trying to protect. It is imperative, therefore, that we derive and make available to everyone our own source of information. If we can find the bugs still waiting to be discovered before the "bad guys" we can then alert the vendor to the problem and get a fix out, hopefully giving people a chance to get there systems patched. Here in lies one of the greatest ironies of such research. Imagine NGSSoftware discover a bug and choose not to alert the vendor but keep the bug secret. Who is to say whether those in the underground would ever find the bug? The vulnerability could lie undetected for the whole shelf life of the vulnerable product. No-one would know a thing save for NGSSoftware. But then what happens if someone else did discover the problem and happily went around popping boxes on the Internet, or worse, wrote and released damaging worm. In the absence of a patch there would be mayhem. So as an industry we must err on the side of caution and alert the vendor and get them to produce a patch. But in doing this the world at large is alerted to a new bug in the product. Had NGSSoftware kept the hole to itself though it could have been that noone would have ever known. We end up in a Catch-22 situation. This has still not justified the publication of a full disclosure advisory, though, with in-depth details and a proper dissection of the vulnerability in question. When a patch has been made available to the public someone who knows their way around computers will be able to compare the patched program and the vulnerable program and spot the differences within minutes - isolating the vulnerable bit of code. A couple of minutes later, and with the use of tools such as debuggers, they'll be able to work out exactly how the program is vulnerable and code up an exploit to take advantage of it. This can all be done without any information other than 1)There is a bug and 2) a copy of the new program and a copy of the old program. Such people, and there are thousands of them, do not need proof of concept code or advisories so even in their absence exploits, worms and virii will still be written and used. So in the interests of "levelling the playing field" it is necessary to publish full details. With these details companies that produce Intrusion Detection/Prevention Devices can update their products more swiftly. Administrators can take steps to modify their firewalls' rule bases to protect their network. Developers of security assessment scanners can add new checks to their products so their users can scan their networks to see if they are vulnerable. Finally there is the educational value in publishing full details with proof of concept source code. If I say to a software developer, "Don't code that way. It's dangerous." they'll probably shrug it off. If I say to a developer, "Don't code that way. It's dangerous and here's why" and then proceed to demonstrate exactly why it's dangerous (their eyes often widen) and they take it on board. They immediately see the threat it poses. So through education developers can learn from others' mistakes. Often CXOs are blind to security issues and it is only when their network administrator proves to them the severity, with the use of proof of concept code, that they understand the impact a vulnerability can have to the business and organizations. [7 of the responses I received to my original posting stated that at some point in the past they've use proof of concept code to get better budgets to enable them to do their job more effectively.] Lastly there is education of the new comers to the security industry. Clients expect the very best from their security professionals - and to give their best security pros need to know the current state of security affairs. Only through education and diligent learning can this be achieved. Without the publication of proof of concept code and vulnerability details this educational gain would be lost - and this in the long run would have a negative impact upon the state of computer and Internet security. External Links: 1. http://www.robertgraham.com/journal/030126-sqlslammer.html 2. http://www.cert.org/advisories/CA-2003-04.html 3. http://www.sqlsecurity.com/DesktopDefault.aspx?tabindex=10&tabid=13 4. http://www.silicondefense.com/research/sapphire/ 5. http://www.nextgenss.com/advisories/mssql-udp.txt - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Thu Feb 06 2003 - 01:33:42 PST