AOH :: ISNQ3428.HTM

Rift Widens Over Bug Disclosure

Rift Widens Over Bug Disclosure
Rift Widens Over Bug Disclosure



http://www.darkreading.com/document.asp?doc_id=113737&WT.svl=news1_2 

By Kelly Jackson Higgins
Senior Editor
Dark Reading
JANUARY 3, 2007

There's a growing rift among the research community over whether the 
Month-of-Bugs initiatives are helping security or hurting it. (See 
Buggin' Out? [1] and Apple Bug Bites OS X, Windows. [2])

There's even now a little pushback from one researcher to the current 
Month of Apple Bugs (MOAB): Landon Fuller, a former engineer for Apple 
and currently with Three Rings, an online gaming developer, is answering 
each MOAB bug with a fix [3] of his own.

This dueling banjos of bug reports and fixes is an example of how 
researchers aren't all on the same page when it comes to how new 
vulnerabilities get disclosed. There's always been a clear line between 
the bad guys and the good, and the underlying argument is not really new 
-- vendors have traditionally maintained a "responsible disclosure" 
stance. But now some of the good-guy researchers are more openly 
questioning just what constitutes proper disclosure of bugs and 
exploits. And the MOAB has become the lightning rod for the debate.

At the heart of the dispute is whether the risk of releasing an 
unpatched bug or exploit is worth the potential improvements in 
long-term security. The point of the MOAB project, according to its 
founders, is to release bugs and exploits without notifying the vendor.

"I think there's a growing consensus that these 'month of XXX' things 
are hurting way more than they're helping," says Thomas Ptacek, a 
researcher with Matasano Security. Ptacek says most researchers have had 
to hold back a vulnerability find for months, "because of a recalcitrant 
vendor."

But for other researchers, there's more of a grey area in the disclosure 
argument. RSnake, a self-described "greyhat" hacker who releases 
discovered vulnerablities, and does a little subversive work, says the 
month-of-bugs projects hasn't run its course. "It definitely has legs, 
but it's for the greyhat folks who haven't yet been burnt" by 
disclosures, he says.

Greyhats, he explains, "may do good, but they also do bad for either 
profit or because they think it serves a greater good," says RSnake, who 
works via the ha.ckers.org and sla.ckers.org groups he founded. "They 
don't fit in either the good or bad category exactly."

RSnake says there are two types of disclosures, one that's difficult to 
exploit and/or won't cause much damage, such as a cross-site scripting 
flaw, and another that's easy to exploit or could do lots of damage or 
is hard to patch, such as zero-day browser exploits that give an 
attacker higher privileges, or some Oracle exploits.

"I opt for corporate [vendor] disclosure very rarely. The only time I 
think it is better for consumers to not know they are vulnerable before 
companies do is if the patch is very simple but the damage would be huge 
if released," he says, such as with OS bugs. "Frankly, I am tired of how 
companies deal with disclosure," says RSnake, who this summer 
experienced the fallout [4] of an XSS flaw on Google's site he reported 
via ha.ckers.org.

Other researchers say releasing a bug before a vendor can respond should 
be the exception, not the rule.

"I've never found it to be a good thing to release bugs or exploits 
without giving a vendor a chance to patch it and do the right thing," 
says Marc Maiffret, CTO of eEye Security Research, a former script 
kiddie who co-founded the security firm. "There are rare exceptions 
where if a vendor is completely lacking any care for doing the right 
thing that you might need to release a bug without a patch -- to make 
the vendor pay attention and do something."

Matasano's Ptacek worries the month of bugs approach will hurt the 
credibility of researchers with vendors. "The most important problem 
researchers have is being ptaken seriously by vendors," he says. "Before 
the 'MOXB' thing, the story could credibly be, 'vendors are shipping 
software that isn't safe to deploy.' Now the story is, 'researchers are 
behaving irresponsibly.' How can they [the MOAB creators] not see that 
this is a win for the vendors?"

But all of the debate hasn't deterred researcher LMH, who heads up the 
MOAB research project and also ran the Month of Kernel Bugs project in 
November. The split among researchers over disclosure, he says, has to 
do with those who have consulting deals with vendors. "If you look 
closely at the parties that do such 'responsible disclosure,' you'll be 
able to draw a red line which separates those who [make] a living out of 
it, and those who stay on the top, far above from the business 
boundaries," he says.

eEye's Maiffret, meanwhile, says plenty of researchers operate based on 
morals, not money. "The reality is you can still be good to business 
while also having ethics in handling vulnerabilities," he says. "There 
are no laws one way or another, and debating people's morals seems to 
never really go anywhere for anyone."

HD Moore, who created the first of these projects, the popular Month of 
Browser Bugs, admits the downside to the Month of Bugs-style disclosure 
is vendors don't get a headstart on patching. But the approach has more 
upsides, according to Moore.

"The awareness piece is still there and it's an effective way of drawing 
attention to a class of vulnerabilities," he says, noting that whether 
to disclose an unpatched or unknown bug or exploit is more of a 
case-by-case situation. "Apple is still getting free security research 
performed on their products. It's an expensive service if you have to 
pay for it," he notes.

[1] http://www.darkreading.com/blog.asp?blog_sectionid=342 
[2] http://www.darkreading.com/document.asp?doc_id=113620 
[3] http://landonf.bikemonkey.org/ 
[4] http://ha.ckers.org/blog/20060706/google-disclosure-fallout/ 

* eEye Digital Security - http://www.eeye.com/html/index.html 
* Matasano Security LLC - http://www.matasano.com/log/mtso/ 


_____________________________
Subscribe to InfoSec News
http://www.infosecnews.org/mailman/listinfo/isn 
 

Site design & layout copyright © 1986-2014 CodeGods