full disclosure

The Future of Vulnerability Disclosure?

by Jeremy Rauch
<jrauch@securityfocus.com>

Jeremy Rauch is a founder of SecurityFocus.com, a Web site that disseminates security information to the public and maintains a number of popular forums and mailing lists, including the Incidents and Bugtraq mailing lists.



Every day, flaws are discovered in software. It's inherent in computer technology that as computers become more and more powerful, and the operating systems and applications become more and more complex and feature-rich, problems are going to creep in. In a lot of cases, these bugs are little more than the nuisances the term "bug" implies. Sometimes, however, the problems are of a less benign nature and have security implications. Flaws — ranging from those that prevent a user from reading email, to those that might allow someone to read millions of people's email messages — can and do happen.

When problems arise, different kinds of actions can result. Often, the person finding the problem will contact the vendor who wrote the product. Other times, the flaw will be discovered because it was used to compromise the security of a machine. Some companies have whole groups of people whose sole mission is to hunt out vulnerabilities in software and work with the vendor in remedying them. In the last five years or so, however, the growth of people participating in what has been dubbed "full disclosure" has skyrocketed. Its critics are as numerous as its champions, and all the commotion often makes it hard to determine just what full disclosure really is and why it works where other methods fail.

The goals of this article are to describe full disclosure, expose its positive aspects, compare and contrast it with more "mainstream" methods, and try to get at the heart of the controversy. I hope the facts about full disclosure, separated from the emotion its supporters and detractors bring to it, will speak for themselves.

What's It All About?

Full disclosure has really come into its own in the last five or so years with the explosive popularity of mailing lists like Bugtraq. Started in 1993, Bugtraq was designed from the start as an open forum for the no-holds-barred discussion of security vulnerabilities. The underlying theory behind Bugtraq and the other full-disclosure mailing lists that followed it was that the only way to improve security is to understand the problems that exist. No more would the details of security problems be limited to closed mailing lists of so-called security experts or detailed in long, overwrought papers from academia. Instead, the information would be made available to the masses to do with as they saw fit.

Naturally, a backlash occurred that has continued to this day. The naysayers argued from the start that full-disclosure mailing lists such as Bugtraq did more harm than good. Arming the hacker "enemy" with details previously made available only to those who were deemed worthy would bring chaos, a security Armageddon. Six years later, and with no collapse of the Internet, there are still those who don't fully appreciate the goals of full disclosure, and very few who understand the impact that full disclosure has, and will have, on security in the future.

Full disclosure, in a nutshell, means disseminating information about security vulnerabilities. It is not about any one aspect; it is not publishing specific vulnerability exploits, nor is it about embarrassing vendors. Its sole purpose is to arm the security-conscious with the knowledge necessary to evaluate risks and take applicable action. This may mean using the vulnerabilities made public in order to audit a network for those vulnerabilities. It might also mean simply downloading patches and installing them. Full disclosure endeavors to give people the flexibility to take what they feel is appropriate action, rather than be hampered by insufficient information.

Full disclosure is in many ways akin to the open-source movement that's taking the computer world by storm. Open source allows for peer review, learning, and collaboration that leads to making better software. Full disclosure has similar goals. By making the details of vulnerabilities public, it seeks to educate and inform, and at the same time to provide a basis upon which to take further action.

For example, buffer overruns were once an obscure topic, but now they have been discussed and dissected to the point where many programmers understand how to prevent them, even if they are incapable of writing an exploit. Where there were once ten new exploits based on the buffer-overrun concept each week, the rate at which they are found has slowed to a trickle. The discussion of these problems in an open, collaborative forum helped to promote understanding, which in turn has significantly reduced the number of vulnerabilities of this type. There are other examples of this —from race conditions to file-permission problems to authentication mechanisms and even simple things like password management — that are now understood by enough people that they no longer plague every other program in existence. In the same way that an open-source project benefits from the input of programmers worldwide scrutinizing its code base, system security has benefited from the scrutiny of full disclosure.

The Critics

Critics of full disclosure argue that the risks associated with publishing information outstrip its benefits. Overworked administrators and security people are incapable of keeping up, they say, and urge that the best route to take is through the vendor, software developer, or one of the multitude of incident-response teams that exist. They take care of fixing the problem and limit the information given out, making it difficult to create an exploit from the information.

This "quiet" approach has two major flaws that have been seen time and time again, however. The first flaw is the assumption that the honest person who reports the vulnerability to a vendor is the first one to uncover it. Exploits often exist in the hands of the so-called "enemy" for months, sometimes even years, before the vendor is notified. The second flaw is that in a number of instances a vulnerability has been reported to a vendor, and in the time between notification and patching, exploits for this vulnerability have floated to the surface. This doesn't necessarily mean that information about security flaws finds its way from the inside vendors into the wild; it can also indicate that for any problem an individual finds, chances are that someone else has already found it or will find it. In the eyes of the full-disclosure advocate, it's better to know about a problem and be unable to obtain a vendor patch than it is to be left exposed, regardless of how tightly guarded a secret the vulnerability is thought to be.

Shooting the Messenger

Vulnerabilities exist whether or not they are found and whether or not they are reported to a vendor or on a mailing list like Bugtraq. This is a fact lost on many people. When software is written, if proper care isn't given to making sure just the proper number of bytes can be copied or that a file being created by root isn't really a symbolic link, a vulnerability exists. It may be found instantly, or it may be found ten years later. It may be quietly patched, or it may make the front page of the newspaper. Often people blame the person who discovers a problem for doing something wrong, when in fact that person was little more than a messenger. Only by identifying the problem can programmers learn from their mistakes and future problems be limited.

Because full disclosure is such a flexible and broad approach to security issues, people are often confused about what the delivery mechanism usually is and just who is doing the disclosing. The most consistently active people in the full-disclosure community are not hackers, as some critics might suggest, but people from a wide variety of backgrounds. System administrators, academics, security consultants, developers, and general security enthusiasts all participate. The information disclosed may be a short note from an individual who suspects that his or her machine was compromised by a given service. It may also be a multi-page dissection of a problem.

Exploits for the problem are often included, but even more common are workarounds and patches developed by individuals as stopgap measures until official patches are available. Contrary to popular belief, vendor notification and full disclosure are not mutually exclusive. Many people choose to notify vendors prior to disclosing information and give details to the public only after the vendor has had an opportunity to address the problem. Since the real goal is to improve security, it is rare for people to post a vulnerability without giving thought to its impact. Posters to the Bugtraq mailing list are always encouraged to notify vendors before sending details to the mailing list.

Full disclosure has its flaws. As many have pointed out, full disclosure does put powerful, dangerous code into the hands of some who may not handle it responsibly. There is always potential for an exploit that is made public to cause major damage. The question that's difficult to answer, however, is: What would the impact of the problem have been had it not been disclosed? Fewer hosts might have been compromised, but whether it would have been noticed is questionable, and the problem might have continued to be a problem. Recently, a vulnerability and exploit for the IIS Web server was released to the public. Millions of hosts were vulnerable, yet relatively few hosts were attacked after the problem was detailed. Patches were quickly issued, administrators were made aware of the problem, and the Web continued to grow without the problems some might have predicted.

Many also point out that often problems that are not being exploited by hackers are made public, as are the means to exploit these problems. It's very difficult to determine just what is being actively exploited in the wild. Simply pointing out that dozens of Web sites are not being defaced is insufficient. In addition, it is often simply a matter of time before these vulnerabilities are found by other parties whose intention may be to keep the vulnerabilities to themselves for nefarious purposes. Vulnerabilities disclosed only to the software author or vendor often seem to rise slowly to the surface in the time between their notification and the patching of the problem; this seriously calls into question whether it's possible to keep a vulnerability secret for long.

With the explosive growth of the Internet, it becomes more and more important to be able to keep abreast of security developments and problems. Full-disclosure mailing lists and newsgroups fill this role perfectly. Vulnerabilities and solutions are disclosed and discussed, and the reader can walk away with enough information to feel comfortable with taking action for the sake of security. The days when one could ignore full-disclosure forums out of some mistaken notion of security integrity are gone. The information being talked about on these lists is the same information being traded among the underground elements looking to break into machines. Only by being well informed can one hope to be secure.

Information about subscribing to Bugtraq and a variety of other mailing lists related to full disclosure and security can be found at <http//www.securityfocus.com>.