Features

Security - how to avoid telling the hackers of vulnerability, while still making sure the users are safe

Security is going to be vital to us wireless data users. When your system turns out to have flaws, you need to be told. But what if you're the hacker - should you still be able to find out? Here, three industry experts put their view on how this should be handled.

A great deal of debate in the vulnerability research community presently revolves around limiting the disclosure of vulnerability information. Indeed, although many prominent researchers have offered their views on this subject, the only actions occurring are at the two extremes - stifling disclosure or simply dumping information into the public domain.

At one end, Microsoft recently influenced the construction of yet another monopolistic paradigm by binding the largest security firms into a collaborative unit. They claim this framework looks out for the security community by preventing the disclosure of vulnerability information until after they (Microsoft) have had time to adequately prepare.

By combining the largest security research businesses into an agreement covering all Microsoft products, they expect to solve many of the issues revolving around full disclosure of vulnerability information. All vulnerability information regarding Microsoft products discovered by companies signed into the agreement will now come from a single point, presumably Microsoft itself. This framework has the following problems:

1 -It only applies to information discovered by bodies signed into the agreement. Other information will be released into public domains in an uncontrolled manner.

2 -By signing into such an agreement with Microsoft, security companies risk alienating themselves from key communities that they had previously relied upon for information.

The security community has had a while to try out Microsoft's new policy on disclosure. It has become clear that there are valid problems with it. One day after Windows XP was released, a vulnerability was found and reported to Microsoft. It was kept secret for almost two months. Workarounds, using such measures are personal firewalls, were available the entire time, but MS intentionally chose not to alert users to them.

The correct answer, for Microsoft or any other vendor, is far simpler than any limited disclosure agenda, and vastly more enforceable - do not sell insecure software! Hire a reasonable number of skilled security staff, and listen to what they say, even if it means that a desired feature has to be left out, or that the product ships a few days later.

The current state of the legal system (which does not hold software manufacturers responsible for product liability) does not excuse poor quality control.

The other end of the spectrum is just as bad. Immediately posting vulnerability information to the web with the hopes that all involved parties will instantly read and assimilate the data is simply irresponsible. Many of the less talented attackers in the hacker community simply download this information and then scan for targets.

There is an alternative, however. Rather than stifling innovation on the good side, simply to prevent black hats from exploiting the systems of overworked administrators, security research should follow a "Responsible Disclosure" model.

All involved parties need to present exploits found in the wild to the vendors first, allowing them the opportunity to correct the issue. Some vendors may ignore such information, but in a free market that is their choice. If vendors do ignore the warnings, then disclosure to a public forum is warranted. In exchange, as our entire system grows more secure, the market will turn away from improperly patched, and therefore insecure, products. Other companies will choose to focus on such valuable information and will reap the rewards of increased market share.

Global InterSec's most recent disclosure (Dec 12, 2001) about glibc vulnerabilities exemplifies this situation. Immediately after discovering the vulnerability, Global InterSec's staff contacted SuSE GmbH (the vendor whose platform was used to research this vulnerability). We gave them the opportunity to correct the problem. Concurrently, Flavio Veloso discovered that the same bug was exploitable and contacted Redhat. Poor vendor communication lead to the disclosure of this vulnerability before SuSE, or any other vendors other than Red Hat, had time to create patches to fix the bugs.

After discovery of the glibc issues, we researched the probable impact of this vulnerability and discovered that it had grave potential. We then contacted the vendor and attempted to control the outflow of information until patches were available. In final analysis, we hope that our impact model for this vulnerability proves entirely incorrect.

The metric depended on the amount of time systems administrators would have to patch their systems before an exploit is developed. Either way, our responsible approach to the entire situation will increase everyone's security posture, not just those out to make a buck.

Michael Morgenstern is Managing Partner of Global InterSec L.L.C. Tom Parker is Director of Operations and Scott Hardy is Director of Research. Global InterSec has offices in New Jersey, California, Florida, and England, and may be reached at info@globalintersec.com