reply: Microsoft: Responsible Vulnerability Disclosure Protects Users
Microsoft: Responsible Vulnerability Disclosure Protects Users
http://www2.csoonline.com/exclusives/column.html?CID=28071
By Mark Miller, Director, Microsoft Security Response Center
Responsible disclosure, reporting a vulnerability directly to the vendor and allowing sufficient time to produce an update, benefits the users and everyone else in the security ecosystem by providing the most comprehensive and highest-quality security update possible.
Provided “sufficient time” doesn’t drag out too long, else the computer criminal (who are in the ‘security ecosystem’) benefit greatly from responsible disclosure too.
From my experience helping customers digest and respond to full disclosure reports, I can tell you that responsible disclosure, while not perfect, doesn’t increase risk as full disclosure can.
Except “your experience” wouldn’t take full disclosure cases into account appropriately. Look at some of the vulnerabilities reported in Windows, Real, Novell and other big vendors. Notice that in more and more cases, we’re seeing the vendor acknowledge multiple researchers who found the issues independantly. That is proof that multiple people know about vulnerabilities pre-disclosure, be it full or responsible. If a computer criminal has such vulnerability information that remains unpatched for a year due to the vendor producing “the most comprehensive and highest-quality security update possible”, then the risk is far worse than the responsible disclosure your experience encompasses.
Vendors only take these shortcuts because we have to, knowing that once vulnerability details are published the time to exploit can be exceedingly short-many times in the range of days or hours.
See above, the bolded “proof” I mention. If vendors are going to move along with their head in the sand, pretending that there is a single person with the vulnerability or exploit details, and pretending that they alone control the disclosure, the vendors are naive beyond imagination.
The security researcher community is an integral part of this change, with Microsoft products experiencing approximately 75 percent responsible disclosure.
I’d love to see the chart showing issues in Microsoft products (as listed in OSVDB), relevant dates (disclosed to vendor, patch date, public disclosure) and the resulting statistics. My gut says it would be less than 75%.
Bogus RFI Reports Getting Out of Hand
I know we’re all getting tired of the Remote File Inclusion (RFI) vulnerabilities being disclosed that end up being debunked, but this one takes the cake so far (yes I’m behind on e-mail).
Fri Jun 16 2006
http://archives.neohapsis.com/archives/bugtraq/2006-06/0321.html
(1) path/action.php, and to files in path/nucleus including (2) media.php, (3) /xmlrpc/server.php, and (4) /xmlrpc/api_metaweblog.inc.php
Sat Jun 17 2006
http://archives.neohapsis.com/archives/bugtraq/2006-06/0447.html
Demonstrated that the vulnerability is bogus.
Mon Oct 30 2006
http://archives.neohapsis.com/archives/bugtraq/2006-10/0486.html
media.php
Mon Oct 30 2006
http://archives.neohapsis.com/archives/bugtraq/2006-10/0501.html
Demonstrated (again) that the vulnerability is bogus.
So not only is it fake, it was also previously disclosed and debunked. I swear, Bugtraq moderators should seriously consider blocking any RFI disclosure from hotmail.com. Would save Vulnerability Databases a lot of time.
January Set As ‘Month Of Apple Bugs’
January Set As ‘Month Of Apple Bugs’
http://www.informationweek.com/news/showArticle.jhtml;?articleID=196701178
The “Month of Apple Bugs” project, which will be similar to November’s “Month of Kernel Bugs” campaign, will be hosted by the kernel bug poster who goes by the initials “LMH,” and his partner, Kevin Finisterre, a researcher who has posted numerous Mac vulnerabilities and analyses on his own site.
More interesting this time, Landon Fuller has begun using his own blog to release unofficial patches for the MOAB vulnerabilities as they are released.
Vulnerability Research Food Chain
I’ve mentioned the sociology aspect of the hacker, vulnerability researcher and security companies before, specifically how they interact, how one will influence another and more. The list of fun ideas I have on these topics is great, and maybe some day i’ll find the time to write more on them. In the mean time, this obvious one popped up and focuses on vulnerability researchers, how they find bugs, and how some feed off the work of others. We see this often where ResearcherA will find a vulnerability in one script, disclose the information, and ResearcherB will followup shortly after with the same type of vulnerability in a different script of the same product.
Recently we’ve seen a rash of remote file inclusion bugs in various add-ons to Mambo and Joomla. These add-ons are typically not written by the same developers nor are they distributed with the base installation of each product. However, they all seem to have one thing in common: “mosConfigabsolutepath” (or sometimes “absolute_path”). The same variable is being exploited in dozens of different add-ons and being found by different people. If we examine the chain of disclosure, can we see patterns in who consistently does followup research (low hanging fruit) instead of finding original vulnerabilities? Are there more observations in the way they are disclosed such as reporting to exploit sites vs Bugtraq or Full Disclosure? Are there misplaced signs of ego that accompany what amounts to trivial vulnerability finds while others are more modest and take it for what it is? Is it surprising that as people jump on the bandwagon, more and more reports end up being inaccurate and not a real vulnerability?
While skimming the list, strike-out text indicates the vulnerability has been disputed or proven false. The names of the researchers who didn’t fully check their find are in bold (and i’m curious if the other disclosures hold up under scrutiny). There is one coinsurance of italics that potentially shows this type of “research” being used in the wild.
2006-08-21 bigAPE-Backup for Mambo – mdx
2006-08-20 Display MOSBot Manager for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-20 EstateAgent for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-19 CatalogShop for Mambo – O.U.T.L.A.W (Aria-security)
2006-08-18 Joomla x-shop – Crackers_Child
2006-08-18 Joomla Rssxt – Crackers_Child
2006-08-18 Kochsuite for Joomla – camino (Insecurity Research Team)
2006-08-18 mtg_myhomepage For Mambo – O.U.T.L.A.W (Aria-security)
2006-08-18 mambo-phphop Product Scroller – O.U.T.L.A.W (Aria-security)
2006-08-17 contentpublisher for Mambo – Crackers_Child
2006-08-17 MambelFish for Mambo – mdx
2006-08-17 JIM for Joomla – XORON
2006-08-17 mosListMessenger for Mambo – Crackers_Child
2006-08-17 anjel for Mambo – Crackers_Child
2006-08-16 Coppermine for Mambo – k1tk4t
2006-08-16 Reporter for Mambo – Crackers_Child
2006-08-16 com_lm for Mambo – Crackers_Child
2006-08-14 MMP for Mambo – mdx
2006-08-14 PeopleBook for Mambo – Matdhule
2006-08-10 Remository for Mambo – camino (Insecurity Research Team)
2006-08-07 JD-Wiki for Joomla – jank0 (hackbsd crew)
2006-07-31 Mambatstaff for Mambo – Dr.Jr7
2006-07-30 UHP for Mambo – Kurdish Security
2006-07-29 artlinks for Mambo – Dr.Jr7
2006-07-29 Colophon for Joomla – Drago84 (Exclusive Security Italian Security)
2006-07-28 Security Images for Joomla – Drago84
2006-07-28 MGM for Mambo – A-S-T TEAM
2006-07-28 Guestbook for Mambo – Matdhule
2006-07-24 PrinceClan Chess for Mambo – Tr_ZiNDaN
2006-07-20 MultiBanners for Mambo – Blue|Spy
2006-07-17 Mambo-SMF Forum – ASIANEAGLE
2006-07-17 VideoDB for Mambo – h4ntu (#batamhacker crew)
2006-07-17 LoudMouth for Mambo – h4ntu (#batamhacker crew)
2006-07-17 PollXT for Joomla – vitux
2006-07-17 Calendar for Mambo – Matdhule
2006-07-17 New Article for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-13 perForms for Joomla – “Vuln founded in a log file: lazy 0day!!! 
“
2006-07-12 Hashcash for Joomla – Ahmad Maulana a.k.a Matdhule
2006-07-12 SiteMap for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-12 HTMLArea3 for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-10 PccookBook for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-07 ExtCalendar for Mambo – Ahmad Maulana a.k.a Matdhule
2006-07-03 Galleria for Mambo – sikunYuk
2006-06-26 CBSMS Mambo Module – Kw3[R]Ln (Romanian Security Team)
2006-06-13 Jobline for Mambo – SpC-x
While all of this not necessarily useful to many, this line of research and observation is fascinating.
The Price of Restricting Vulnerability Publications
The Price of Restricting Vulnerability Publications
by d2d
http://www.ijclp.org/Cy2004/ijclpwebdoc10_Cy2004.htm
The Price of Restricting Vulnerability Publications by Jennifer Stisa Granick
Abstract
There are calls from some quarters to restrict the publication of information about security vulnerabilities in an effort to limit the number of people with the knowledge and ability to attack computer systems. Scientists in other fields have considered similar proposals and rejected them, or adopted only narrow, voluntary restrictions. As in other fields of science, there is a real danger that publication restrictions will inhibit the advancement of the state of the art in computer security. Proponents of disclosure restrictions argue that computer security information is different from other scientific research because it is often expressed in the form of functioning software code. Code has a dual nature, as both speech and tool. While researchers readily understand the information expressed in code, code enables many more people to do harm more readily than with the non-functional information typical of most research publications. Yet, there are strong reasons to reject the argument that code is different, and that restrictions are therefore good policy. Code¹s functionality may help security as much as it hurts it and the open distribution of functional code has valuable effects for consumers, including the ability to pressure vendors for more secure products and to counteract monopolistic practices.
Site Specific Vulnerabilities
The argument that Vulnerability Databases (VDBs) are evil because they provide the bad guys all of the information on how to hack has gone on for quite some time. Of course, this debate crosses over into the Full Disclosure argument, which asks the question, should the information be public at all? But for VDBs, the real question should not be about whether to provide information on vulnerabilities, but how specific the information cataloged should be?
Some believe that providing exploits or tools to make it easier to exploit a vulnerability is where it crosses the line on providing too much information. While there may be a few valid points on the topic, the real issue, in my opinion, is when resources provide vulnerability information in the context of a specific site/domain.
VDBs are not the only resource that may have site specific vulnerability information. Many search engines such as Google/Yahoo have come under fire as being a collection of security information to assist attackers. In fact, it could be argued that the search engines pose greater security disclosure problems than a VDB, since a search engine takes an attacker immediately to a vulnerable website. There is even a whole site (and following) centered around using Google to quickly find specific vulnerable software on web sites.
OSVDB has a policy that we do not catalog site specific vulnerabilities, and we make all efforts possible to avoid these entries being added to the database. In fact, quite a few VDBs follow this same practice. However, some VDBs will include sites specific vulnerabilities only for high profile websites. For example:
XSS vulnerabilities in Google.com: http://www.watchfire.com/securityzone/advisories/12-21-05.aspx
Google GMail ‘CheckAvailability’ Script May Disclose User Information to Remote Users: http://www.securitytracker.com/alerts/2004/Jul/1010647.html
Yahoo! Mail ‘order’ and ‘sort’ Field Input Validation Flaw Permits Cross-Site Scripting Attacks: http://www.securitytracker.com/alerts/2004/Mar/1009352.html
It is important to note that certain advisories make it very hard to determine if the issue is in a product or on a website. Recently, we have seen what appears to be more site specific issues being released by researchers. For example:
SpearTek Search Field Handling Cross Site Scripting Vulnerability: http://www.frsirt.com/english/advisories/2005/3052
There appears to be quite a few advisories released by r0t that may fall into the site specific category. If you look on r0t’s site, anything that says there is a XSS vulnerabillity in the “Search Module” may very well be a vulnerability in the company website, not in the product–even though he lists version numbers in the advisory.
Considering VDBs such as OSVDB do not have the resources to verify all advisories, we must rely on the information provided, and in some cases site specific vulnerabilities make it into VDBs by accident. In fact, dozens of entries in OSVDB currently have internal flags on them as we try to determine if they are site specific.
Providing a company website or an online service that has a security issue is not something that OSVDB believes to be appropriate, even though many contributors personally find it extremely interesting, and believe it is valuable. Many organizations that rely on online services may find great value in knowing about an issue with their online email provider. The fact that many businesses use sites like Google, Gmail, or Yahoo heavily suggests that vulnerabilities in the services are just as dangerous as vulnerabilities in the software deployed on their own network.
It may make OSVDB look incomplete compared to VDBs that include site specific vulnerabilities, but we are willing to accept that risk. The OSVDB project aims to provide useful information to help improve the level of security for the community, and site specific vulnerability do not fall in that category currently.
