| |||
|
|
||
|
|||
| |
|
Home > Security News > Flaw disclosure debate polarizes SOURCE Boston panel |
| |
|
|
|
|
| Security News: |
|
||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
BOSTON -- Has the security researcher community given up all hope of full disclosure that it has resigned itself to debating partial disclosure? And is partial disclosure the new responsible disclosure? Those are heady and polarizing questions; so much so that two hours of spirited sparring Thursday during a panel discussion at SOURCE Boston brought us no closer to answers. But it was fun. The five-person panel, moderated by Kaspersky Labs security evangelist and blogger Ryan Naraine, joined independent and vendor researchers, some of whom were recently in the disclosure firestorm. The group hashed out a litany of issues, veered off on a few tangents about vendor trust and patching, and conducted a referendum on last summer's Dan Kaminsky DNS patch controversy. Kaminsky sat on the far right end of the dais Thursday, but he was front and center for much of the conversation, which immediately took aim at his partial disclosure of details of the DNS cache poisoning flaw he found last spring. Kaminsky chose only to disclose publicly that there was a serious vulnerability in DNS implementations and urged infrastructure managers worldwide to deploy an unprecedented multivendor patch that he helped coordinate. Companies had to make an incredibly difficult call without precious details on the flaw. Kaminsky hoped to keep the facts quiet until his presentation at the Black Hat Briefings in August, but other researchers made reasonably educated guesses about the details and spilled them on a blog. Quickly, crackers had a working exploit posted to the Metasploit framework and the cat was out of the bag, and the bashing began on Kaminsky's strategy.
During the discussion he defended his altruism, and the practice of partial disclosure, saying that he wanted to provide DNS operators with enough advance notice of a problem, recognizing the difficulty of tinkering with infrastructure, as opposed to endpoints for example. He said he was counting on admins' trust in the number of vendors—including Microsoft, VeriSign and Cisco—who helped build the patch that the problem was serious enough to warrant immediate action. "It's reasonable to say there are two different populations of admins: those who won't deploy a patch unless things are blowing up or they see an exploit in Metasploit, or another group who either listen to their vendors or the government," Kaminsky said. "There was a serious population of people who said 'Wow, the industry is aligning to deploy a patch, let's deploy.' That second category is nice to see. Every bug shouldn't have to be a worm before we patch it." Kaminsky added that the biggest spike in early adopters of the patch happened around the time the exploit appeared in the wild; most patched within 30 days, which is still an extraordinary timeframe said fellow panelist and researcher Dino Dai Zovi. Dai Zovi, former director of security at a hedge fund, was the first researcher to whom Kaminsky showed the bug, and said it was a huge leap of faith for admins to patch these systems and essentially put their jobs on the line with so little detail publicly available. "If it goes wrong, look at their risk calculation. You have an unspecified vulnerability with mostly specific consequences, that needs to be patched, yet there is no immediate danger," Dai Zovi said. "If the patch breaks something; firewalls break, now with 100% certainty your networks are down and you are at risk."
At the other end of the spectrum, yet seated immediately to Kaminsky's right was Alexander Sotirov. In December, Sotirov and a team of researchers that included Jacob Applebaum and Marc Stevens partially disclosed details of a bug in SSL certificates whereby collision attacks could be conducted against MD5 certificates. Certificate authorities such as VeriSign Inc. and browser makers Microsoft and Mozilla were advised of the issue and urged to revamp before the details were disclosed publicly at the Chaos Computer Congress. Sotirov, though he worked with the affected vendors, indicated yesterday that some short term pain in terms of disclosure is worth the long-term gain of getting vendors to react quicker to vulnerabilities. He offered the 1988 appearance of the Morris worm, which exploited buffer overflows to spread about the nascent Internet, as a lost opportunity. Another worm exploiting buffer overflows on such a scale did not appear again until 2003, and Sotirov says that had researchers addressed the problem immediately, the plague of worms in 2003 and 2004 could have been avoided. "Having some kind of pain in short term, like breaking DNS now when not as many things rely on it as they possibly would in 5 years [is worth it]," Sotirov said. Sotirov said Kaminsky missed an opportunity to teach vendors that they need to take care of systems and infrastructure, and instead gave them leeway to go without patching for 30 days. He equated this to failing to punish a misbehaving child. "Next time when Dan finds a bug, they think they will always have enough time and won't have to think about doing patches more quickly," he said. Panelist Ivan Arce, chief technology officer of Core Security Technologies wasn't quite in Sotirov's corner as to using exploits as tools to teach vendors lessons, but he wasn't fully behind Kaminsky's course of action and attempt to make a patching decision on behalf of DNS administrators. "There are admins driven by fear or those driven by recommendations from security vendors or experts. I'd like to think there is a third category, which is those admins and people who would like to manage risk in a rational manner and analyze their situations," Arce said. "To those guys, you need to give them tools if you want to help them to make rational decision." Microsoft senior security strategist Kate Moussouris, another panelist, called for a common language and trust between the research community and IT administrators to make infrastructure resilient.,/p> "At Microsoft, we have a Security Development Lifecycle we use to help us build more secure software from the ground up," Moussouris said. "What we need to extend to infrastructure is a development to deployment lifecycle. We need more collaboration between those who say the sky is falling, and those whom the sky falls upon." Arce concluded that security is improving—incrementally. "In order to make that pace faster, we need to provide more technical detail in a transparent manner, and help people make decisions by themselves," he said.
|
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||
|
|||||||||||||||||||||||||||
| |||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
