Security researchers and vendors--a truce?

There has historically been a clash between security researchers who find security flaws in software products and the companies that make those products.

But two recent examples of cooperation between researchers and vendors show hope for future truces.

Leading by example was Dan Kaminsky, director of penetration testing for IOActive, who warned security software vendors about a fatal flaw in the DNS (Domain Name System) months before going public so vendors could release patches.

"What he and others he took into his confidence did over the last few months was not only responsible but extraordinary," my colleague Robert Vamosi wrote in a column about Kaminsky's unprecedented disclosure restraint.

This week, security researchers Robert "RSnake" Hansen and Jeremiah Grossman agreed to withdraw their presentation on a new Web attack they dubbed "Clickjacking" from an upcoming OWASP USA security conference in New York at Adobe Systems' request. Now, Adobe can create a patch for one of its applications before they release proof-of-concept code for the vulnerability, which would allow an attacker to take over the microphone, Webcam, and audio on a computer, according to a report on the Dark Reading site on Tuesday. (Oddly, the vulnerability is actually due to an architectural issue in Internet Explorer, the researchers say.)

"I've always had this philosophy. If you find a mediocre to bad vulnerability, it's better to just talk about it, get it out in the open, and let the world see it," RSnake wrote in a first-person account of the situation on Dark Reading. "However, I've always told myself if I found something like a complete remote desktop compromise or something equally bad, that I'd let the vendors know. The last thing I want to do is spawn a botnet army based on my research. There's a big difference between educating the community about a problem and empowering bad guys."

Most of the researcher-vendor conflict comes down to a matter of timing. Vendors tend to want researchers to keep mum until a fix is ready. And researchers want to go public sooner rather than later so that people relying on those products will know they are at risk. Also, going public can serve to motivate a vendor who might be dragging their feet on acknowledging and fixing the problem.

In 2002, Hewlett-Packard threatened to sue researchers who had publicized a vulnerability in the company's Tru64 Unix operating system. The case was notable in that it was the first time the Digital Millennium Copyright Act had been invoked to stifle research related to computer security.

Previously, the DMCA had been used to prosecute or threaten researchers who had discovered ways to break copyright protections. For instance, Russian programmer Dmitry Sklyarov went to jail in 2001 after Adobe convinced the Justice Department that he had violated the DMCA by breaking e-book protections, but he was later released. And Princeton University professor Edward Felten and his students withdrew a paper on how to break e-music protections after being threatened by the recording industry.

In 2005, Cisco Systems filed a lawsuit against security researcher Michael Lynn just hours after he gave a presentation at Defcon about how attackers could take over Cisco routers. That case was ultimately settled.

These threats and legal actions are unnecessary. Kaminsky, Hansen, and Grossman have shown that there can be compromise. That's a good lesson for three MIT students who pulled a talk at Defcon this summer on hacking the Massachusetts subway system, and for the transit officials who hauled them into court.

[krsecurity]

This is a great story. Nice to see someone paying attention to this issue.

I have a few things to add. Before a couple of years ago, there were informal protocols for bug/vulnerability reporting and most folks acted responsibly (alerting the company, giving them a chance to fix it, then announcing publicly after a reasonable time passed) . But maybe three years ago, a new phenomena started to emerge that changed the dynamic. I worked for a large security vendor at the time a few years ago, and some independent researchers turned into little more than blackmailers. They'd reverse engineer products, find a vulnerability, then ransom it to the vendor-with the threat of immediate release to the media if payment wasn't made. (And the media did cover it if you didn't pay). Some of these "researchers" are still occasionally quoted as legit. Those who have paid these guys in the past get great reviews, and those who didn't are panned. It still today pisses me off seeing anyone base their opinions on such garbage, but no one can say anything because they end up looking like they aren't taking responsibility for the product's security issues.

This doesn't go for all reverse engineers or researchers. I'm friends with many who are very conscientious and reverse engineer to help improve overall security (and when they'd approach us with a bug it was not unusual for us to contract with them to help us fix it). But the media should beware those researchers who actively seek them out with reports of breaking news vulnerabilities, because there's often an ugly side of the transaction they don't see.

[mbenedict]

It's not just DMCA.

Apple for example is notorious for using NDAs to silence security researchers.

Many Apple tools (most recently, the iPhone SDK) are covered under NDAs. If you find an iPhone security issue, you can't publish it -- even with prior disclosure to Apple, and even after a patch is available -- because they will sue you under the NDA.

So really Apple uses NDAs as a backhanded way to hide security issues from the public. And you know what they say about security by obscurity.

Another example of this is when a security researcher found a weakness in Apple's FileVault disk encryption system. Apple forced him to pull his talk from the Black Hat conference last month, using this NDA provision.

More on this (goes to Infoworld): http://qwix.com/29