TISC Insight, Volume 3,Issue 3

Welcome to Volume 3, Issue 3 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community. Many of our columnists teach and speak at The Internet Security Conference.

Previous issues are posted here.

TISC is about sharing clue. So is the newsletter. We promise to provide something useful each issue. If we don't, flame me.

Enjoy, and be safe,

Dave

You discover a bug in a security product. What do you do?

1. Contact the vendor, explain the problem, provide good documentation, encourage the vendor to disclose the vulnerability with a patch.
2. Call an emergency session of Congress.
3. Contact a bug reporting agent--BugTraq, CERT, whomever...
4. Post it on a newslist because it will help people appreciate how clever you are.
5. Call a reporter, hope he will convince his editor to make it a front page story.

Just about all of these are practiced today. In today's column, Ivan Arce discusses the seriousness, nature, and complexity of vulnerability reporting, and suggests that every practicing security professional, user, hobbyist, and developer has a role and responsibility in vulnerability reporting.

Enjoy.

During the past 3 years, I've been involved in the discovery and research of different types of security vulnerabilities in software that lead to the process of producing meaningful reports, notifying the interested parties (vendors and the public in general) and accompanying those parties throughout the process of generating fixes and deploying them.

Last December Microsoft organized SafeNet2000, an invitation only gathering of 250 experts of the information security area to discuss issues related to privacy and security in our times. I was invited to the summit and participated in the Vulnerability Reporting track. Several well known computer security experts from a wide range of interested parties-vendors, consulting firms, government and military, and end customers--tried to agree on a set of guiding principles for the report of security vulnerabilities.

Thus, an attempt to understand and formalize the process of reporting vulnerabilities is underway. But this effort is in its infancy. This column puts the issue of vulnerability reporting in the public eye, to motivate information security professionals and other interested parties to participate in this effort.

So what are we talking about when we use the term vulnerability?

A vulnerability is a bug or flaw in any component of a given IT infrastructure that can be exploited, and a consequence of doing so that the security policy that applies to the mentioned IT infrastructure would be breached.

The above definition is both very general and precise. We generally tend to think of vulnerabilities as software bugs. However, design flaws in software and hardware, botched administrative processes, the lack of awareness and education in information security and several other factors can become "vulnerabilities" using this broad definition.

So let's focus on vulnerabilities that are consequence of software or hardware bugs or design flaws. Let's assume that during the course of our regular activities, professional, educational or even as a hobby or by accident, we discover a vulnerability. Does the discovered bug lead to a breach of the security policy if it is exploited? Whether the answer to this question is yes or no depends on the infrastructure where the bug is present. However, the topic before us is whether a vulnerability report should be issued to the proper parties if we need the bug fixed. We also need to ask

"Why should it be reported?" "How should it be reported, and to whom?" "What are the guiding principles for such a report?

Quoting the excellent preface to the SafeNet2000 working group conclusions, worded by Van MacLellan:

"Information technology professionals have a responsibility to promote awareness of, and resolution to, vulnerabilities that threaten user communities"

Further more, it is not only a professional obligation as much as a necessity for the common health and survivability in this "connected" world.

Not only the IS professional, but the hobbyist, the administrator and the end users should responsibly report vulnerabilities discovered if they are believed to be unknown to the rest of the world.

Information as well as revolutionary ideas in the information security arena are not exclusive to a small elite of enlightened individuals: they are part of a moment and a generalized view of the field. Keeping vulnerability information secret is pointless: sooner or later it will become public anyway.

"Previously undiscovered security flaws in widely used HW and SW should not (and will not) remain secret indefinitely".

The Cast

Lets identify the different players in the process of reporting and fixing bugs:

The Process

Usually, the process followed for the disclosure of a vulnerability report includes at least 3 of the players:

The discoverer finds what it is believed to be a new bug. Research is then conducted to verify that it is in fact a bug, that it is in fact exploitable and poses a risk to the infrastructure where it was found, and that it is in fact a new bug, neither documented nor previously reported to the vendor.

A draft report is then written, detailing what the problem is, how it was found, how it can be reproduced, affected software (generally not a complete list) and an initial assessment of the impact of exploitation of the problem.

The discoverer then obtains contact information for the vendor or vendors (email addresses, PGP/GPG public keys, phone numbers, etc.) and submits the report to the vendor through the proper channel.

Upon reception of the report, the vendor verifies that the bug actually exists and determines which products are affected. This generally involves communication with the discoverer in order to assist the vendor in understanding and reproducing the problem. The vendor then embarks in the process of producing fixes or workarounds for all the affected products. For doing so, the vendor must assign enough resources to solve the problem in a timely fashion.

Once fixes are produced, tested and ready to ship, public release of the vulnerability information is coordinated between vendor and discoverer. The release of a vulnerability report is generally done through two different channels: public forums (security mailing lists, newsgroups, web pages, etc.) and vendor specific channels (customer mailing lists, press releases, vendor web pages, etc.).

This is how the information reaches the user. It is now the user's turn to address the problem. This involves assigning resources to verify the existence of the vulnerability and the impact of exploitation in the user's infrastructure, obtain the proper fixes from the vendor and apply them according to a deployment plan that is particular to the user organization.

Bugs in the bug reporting process

The above is a simplistic description of the vulnerability reporting process, and various problems can arise. In the Real World ô several things happen that make the whole process fail:

The discoverer does not have the skills nor the time to produce an in depth research of the problem, thus it is not easy for the vendor to determine if the problem actually exists, if it is specific to the discoverer's infrastructure or what the impact of exploitation is.

• The discoverer does not have the resources or will to assist the vendor through the process of identifying the problem.
• The vendor does not address security problems in a timely fashion, either because of lack of interest, or because of lack of resources.
• Communication between discoverer and vendor is not accomplished in a simple, clear and cooperative way. This could happen because the discoverer choose (for whatever justified and often unjustified reason) not to inform the vendor about the problem and go directly to the forum publishing stage, because the vendor is not responsive or does not provide feedback on his/her plans to address the problem and release fixes.
• There are several discoverers that find the vulnerability independently at the same time and each one them use different procedures for disclosure, generally leading to lack of coordination or leakage of information before fixes are ready.
• There are several vendors affected by the vulnerability and they do not cooperate with each other (for whatever justified or unjustified reason). Coordination of in the release of information and fixes to the public is not possible.
• The vulnerability is known to be actively exploited and delaying its disclosure will put at risk all the users, thus immediate release of information is in order.

These are but a few of the problems that arise in the vulnerability reporting process. Some of them can be addressed if other parties are involved in the process. The role of the proxy can be very helpful to both discoverers and vendors if resources to address the problem are scarce. The proxy can coordinate the communication between parties, perform the initial contact information gathering effort and even, in some cases, conduct its own research on existence, exploitability and impact of the vulnerability.

The trusted third party can be of great help if communications between discoverers and vendors are not smooth and cooperative. But the bottom line is that the process of finding bugs, reporting them and getting them fixed can become a very serious and complex matter.

So what are some basic guidelines for the vulnerability reporting process?

The guidelines: A feeble attempt at improving the process

(1) Vulnerability reporting costs money: Keep it simple and everybody wins.

All the involved parties (discoverer, proxy, vendor, trusted third party, user) must invest a certain amount of effort to fix bugs. All parties have finite resources and therefore it costs them money. Streamlining the process and addressing the problems in a responsible and timely fashion reduces the efforts for all parties.

(2) Communication is key.

The best way to streamline the process and ensure cooperation is to maintain every party informed of what is going on. When that fails, unilateral actions take place that could put all at risk.

(3) Minimize harm.

Conduct all activities bearing in mind that the end goal is to improve the overall security and minimize the harm to all parties. Although this sounds obvious, the ultimate goal can be obscured during the process, evaluate your actions accordingly.

Extend the benefit of doubt, do not impute motives.

If all party follows the same guidelines and problems still arise it is common sense to adjudicate them to unintentional misunderstandings, it is equally easy to determine when bad intentions are involved.

Conclusion

Since I started writing this column, several events related to the very same topic have become public. Dozens of reports of new vulnerabilities have been published, different views of how the process should be have been expounded and no formal attempts to rationalize them have been made.

It is, perhaps, a good time to formalize and implement a vulnerability reporting process.

© 1999 - 2006 Core Competence & Mactivity, Inc