1

British Columbia Institute of Technology

Debate on Full, Responsible and No disclosure as it applies to Security vulnerability

Author: Arif Zina

 2

Disclosure debate

Vulnerability is a bug; it’s a programming mistake made by programmers during the product’s
development and not caught during testing. It’s an opening that someone can abuse to break into
the computer or do something normally prohibited.
Vulnerability disclosure is the practice of publishing information about a computer security
problem, and a type of policy that stipulates guidelines for doing so. Either the person or
organization that discovers the vulnerability or a responsible industry body such as the Computer
Emergency Readiness Team (CERT) may make the disclosure, sometimes after alerting the
vendor and allowing them a certain amount of time to fix the problem before publishing the
information.

The question of how much information to provide and when to make it public is a contentious
issue. Some people argue for full and immediate disclosure, including the specific information that
could be used in an exploit. In computing, an exploit is an attack on a computer system,
especially one that takes advantage of a particular vulnerability that the system offers to intruders.

Disclosure, or perhaps non-disclosure of such vulnerabilities in software has raised debates on

how much of this information should be made public. Scott Culp, manager of the security
response centre at Microsoft, published an essay describing the practices of publishing security
vulnerabilities. He claimed that we’d be a lot safer if researchers would keep details about
vulnerabilities to themselves, and stop arming hackers with offensive tools. The basic value
proposition of vulnerabilities finding is simple: It is better for vulnerabilities to be found and fixed
by good guys than for them to be found and exploited by bad guys. If a vulnerability is found by a
good guy and a fix is made available, then the number of intrusions and hence the cost
intrusions, resulting from that vulnerability is less than if the information was made public and
making black-hat communities aware of such deficiencies. Therefore, Those against the full-
disclosure movement argue that publishing vulnerability details does more harm than good by
arming the criminal hackers with tools they can use to break into systems. Security is much better
served, they counter, by keeping the exact details of vulnerabilities secret.

On the other hand, by fully disclosing, software-manufacturing companies are forced to take
security issues seriously and attempt to build quality software from the beginning and to fix the fix
vulnerabilities before the product is released.

During the early years of computers and networks, bug secrecy was normal. When users and
researchers found vulnerabilities in a software product, they would quietly alert the vendor. After
CERT was founded in 1988, it became a centre-point in ensuring that vendors fixed security-
holes in their software. People would send newly discovered vulnerabilities to CERT. CERT would
then verify them, alert the vendors, and publish the details (and the fix) once the fix was available.
The problem with this system is that the vendors didn’t have any motivation to fix vulnerabilities.
CERT wouldn’t publish there was a fix, so there was no urgency. There were incidents of vendors
threatening researchers if they made their findings public, and smear campaigns against
researchers who announced the existence of vulnerabilities. And so many vulnerabilities
remained unfixed for years. The full disclosure movement was born out of frustration with this
process. Once vulnerability is published, public pressures give vendors a strong incentive to fix
the problem quickly. For the most part, this has worked. Many researchers publish vulnerabilities
they discover on mailing lists such as Bugtraq. The press writes about in the computer
magazines. The vendors scramble to patch these as soon as they are publicized. The full
disclosure movement is therefore, improving the Internet security as a whole.

As with Nondisclosure, responsible vulnerability disclosure addresses how a vulnerability

identifier should disclose vulnerability information to appropriate people, at appropriate times, and
through appropriate channels in order to minimize the social loss associated with vulnerabilities.
Despite the consensus on the objective of responsible vulnerability disclosure, the perception
 3

about what constitutes responsible vulnerability disclosure has changed over time. During the
early days of software development, the common practice was to inform only the vendor about
the discovered vulnerability and to keep it secret from the public until the vendor developed a
patch was the common practice. In responsible disclosure, vulnerability information is shared
among as few individuals as possible. During the initial phases of disclosure only a small group is
allowed access to the full details of the vulnerability. This group consists of the discloser, the
vendor and possibly a third party coordinator. Without mandatory public disclosure there is
nothing to motivate the vendor to develop a timely fix unless the discloser threatens to go public if
the deadline by the vendor is not met for a fix. Since the vendor can delay the final disclosure
until they have fixed the flaw, the black hat might have already seen this vulnerability and could
be compromising systems without systems administrators being aware of it. Also due to minimum
information provided, it can became very difficult to understand the flaw thoroughly and therefore
putting customer at a greater risk because of not knowing what to do in order to protect their
systems.

Description of disclosures and their pro’s and con’s

Nondisclosure

To have a policy of Nondisclosure means to keep the vulnerability information tightly

contained so as the general public never learns of its existence. Some vendors and security firms
have tried to promote a policy of Nondisclosure. They feel that the vulnerability information can be
controlled and only “trusted” individuals will be informed. The black hat community practices a
policy of Nondisclosure. When a vulnerability is discovered by a black hat the information is kept
by that individual or judiciously distributed within a black hat group. These black hats then use the
vulnerability to penetrate unprotected systems for whatever clandestine purpose they desire.
Eventually the vulnerability information leaks out and is released in a public forum. However,
before this time systems and their administrators have no defense against exploitation.

Some vendors and security firms have tried to promote a policy of Non disclosure.They feel that
the vulnerability information can be controlled and only “trusted” individuals will be informed. In
this way they can “protect” the vulnerable systems until a fix can be made available. The major
flaw with this thinking is the belief that the information can be controlled. There is no way to
assure that the selected individuals can be trusted not to use privileged vulnerability information
for their own gains. Furthermore some of the individuals employed by vendors and security firms
have questionable histories. Can we really trust “reformed” individuals with past careers as black
hats to act responsibly with privileged vulnerability information?.

Adopting a policy of Nondisclosure has several disadvantages and few advantages. On the
advantage side, a Nondisclosure supporter might argue that controlling the disclosure of a
vulnerability will help keep the information out of the hands of black hats. However there is no
way to assure that the black hat community does not already possess the vulnerability
information or that they will not discover it on their own before a public disclosure is made. The
only real advantage of Nondisclosure is to the vendor alone. If a vendor can keep a vulnerability
secret while it is fixed the vendor can avoid any negative press that may be generated.

There are numerous disadvantages to a policy of Nondisclosure. First if vulnerability information

is leaked or simultaneously discovered the black hat community has an opportunity to actively
exploit the vulnerability. Systems will be left exposed during the time it takes for the software
vendor to patch the product. Second since the vulnerability is not disclosed publicly
administrators do not have the opportunity to protect vulnerable systems. Next because there is
no negative press for the software vendor they are not motivated to repair the flaw in a timely
manner. Finally it is impossible to define who is the “trusted” subset of individuals that should
have access to sensitive vulnerability information.
Because of these reasons a policy of Nondisclosure is obviously less than desirable.
 4

Full Disclosure

Full disclosure means to disclose all the details of a security problem which are known.
It is also a philosophy of security management completely opposed to the idea of security through
obscurity, and that is what this article discusses.

Full disclosure requires that full details of a security vulnerability are disclosed to the public,
including details of the vulnerability and how to detect and exploit it. The theory behind full
disclosure is that releasing vulnerability information immediately results in quicker fixes and better
security. Fixes are produced faster because vendors and authors are forced to respond in order
to save face. Security is improved because the window of exposure, the amount of time the
vulnerability is open to attack, is reduced.

Computer vulnerabilities disclosure is often achieved via mailing lists such as Bugtraq and full
disclosure by other means.

Supporters of Full Disclosure argue several advantages. Firstly a vendor is motivated to provide a
timely patch or workaround to a new vulnerability. If the vendor fails to provide a timely fix and a
vulnerability is disclosed fully and the resulting negative media will cause damage to the vendor’s
reputation and revenue. Further, in order to avoid future negative media a software vendor is
motivated to create less vulnerable products. Next, Full Disclosure advocates state that black hat
hacker community is already aware of vulnerabilities. By fully disclosing vulnerability information
administrators of vulnerable systems are armed with the information needed to take action. Full
Disclosure supporters believe that it is imperative that administrators and programmers fully
understand vulnerabilities in order to prevent and defend against them. They believe that
because administrators and programmers have access to full technical details of the vulnerability
they can take appropriate defensive action.

Defensive action can be any or all of the following: developing and implementing an Intrusion
Detection System (IDS) signature to allow detection of the exploit and implementing a temporary
workaround such as shutting down a vulnerable service or blocking traffic at a firewall. In addition
to these defensive actions a systems administrator might use exploit code to scan the network for
vulnerable systems or to test the possible vulnerability of systems that have been patched. Also
programmers can review the structure of the flaw and attempt to avoid similar situations in future
development.

The disadvantage of full disclosure id that the vendor does not have grace period to address the
flaw after it has been fully disclosed. In Full Disclosure the vendor is notified at the same time as
the vulnerability information is fully disclosed. Because of this, systems are vulnerable during the
amount of time it takes the vendor to address the vulnerability. While it is true that talented black
hat community may likely have prior knowledge of an exploit, the hordes of script kiddies do not.

Those against Full Disclosure argue that fully disclosing a vulnerability including exploit code,
arms the script kiddies. Next oblivious of any technical knowledge but armed with the automated
exploit the script kiddies proceed to launch attacks upon the Internet public. Finally if the talented
black hats do not posses prior knowledge of a new vulnerability Full Disclosure makes it
considerably easier for them to develop exploit code and automated tools.

Responsible Disclosure

Responsible disclosure can be explained as a process which takes place from the time a
vulnerability is discovered to deployment of patches. The stages for his process can be explained
as follows:
 5

1. Discovery

During this stage of the vulnerability life cycle the method of discovery will determine
how responsible disclosure will be proceed. There are two ways that a vulnerability
can be discovered. First a responsible party such as a security firm, white hat, or
vendor programmer can discover the vulnerability. Second evidence that a black hat
has discovered the vulnerability can be uncovered. In the first situation access to
vulnerability information can be controlled until a patch has been developed and a
public disclosure can be made. In the second situation the vulnerability is already
being actively exploited therefore a public disclosure must be made in order for
customers to defend their resources.

2. Initial Contact

The discloser should always notify the vendor before any public disclosure is made. This
contact should be done in such a way as to confirm that the vendor has received the
notification. If possible all communication should be secured to avoid premature leakage
of vulnerability information. Next a reasonable deadline for vendor response should be
purposed and agreed upon. The generally accepted deadline is 30 days. However there
maybe mitigating factors that demand the deadline be shortened or extended.
Regardless of mitigating factors the deadline should not be extended indefinitely. Finally
an effort should be made to keep the circle of trust small. It is important that knowledge of
the vulnerability be kept secret until a patch can be developed.

3. Continued Communications

During the time after initial contact and until public disclosure all communication lines
between the vendor, discoverer, and originator should be kept open. Any
miscommunication during the entire disclosure process could lead to premature
disclosure and the exposure of customer resources.
It is important that the vendor attempt to reproduce the vulnerability in order to verify
its existence. If involved a third party coordinator may attempt reproduction as well.
The originator should provide the vendor and coordinator with all the necessary
information and aid reproduction in any way. If the vendor does not respond to initial
contact or fails to continue communication the originator has no option but to proceed
with public disclosure without a vendor supplied patch.

4. Patch Development

The vulnerability life cycle correction stage commences once patch development starts.

Responsible Disclosure therefore maintains a balance between making the vulnerability public
and giving vendors enough time to correct the issue. The advantages would be that the
vulnerability will be kept at a strictest confidence until a patch is released. The disadvantage
would obviously be that the black-hat is already aware of this vulnerability has already developed
a hacking tools to compromise systems without administrators being aware of this issue.

An example of an actual attack in which the disclosure of security vulnerability played a part is as,
SQL slammer worm.

The CERT/CC has received reports of self-propagating malicious code that exploits a
vulnerability in the Resolution Service of Microsoft SQL Server 2000 and Microsoft Desktop
Engine (MSDE) 2000. This worm is being referred to as the SQLSlammer, W32.Slammer, and
 6

Sapphire worm. The propagation of this malicious code has caused varied levels of network
degradation across the Internet and the compromise of vulnerable machines. The patching and
other information was also posted on the CERT website: http://www.cert.org/advisories/CA-2003-
04.html.

My standpoint on this debate

I support responsible disclosure. Responsible Disclosure maintains a balance between making

the vulnerability public and giving vendors enough time to correct the issue. The advantages
would be that the vulnerability would be kept at a strictest confidence until a patch is released in a
reasonable time. Unfortunately, if the black-hat community becomes aware then, a full-disclosure
is required.

Legal and law-enforcement position

In the USA, currently there is no law for disclosure but the congress likes the idea of no
disclosure and could end up accepting it. Microsoft is a major supporter of no disclosure and is
lobbying this to the government.

In Canada, I was not able to get any information on any initiatives for passing a law on this
regard.

Bibliography

Http://www.cert.org

Is finding security holes a good idea - Eric Rescorla, RTFM Inc

Crypto-Gram Newsletter - Bruce Scheiner, Nov 15, 2006

B
5.
6. 5 06E4 A169 4E46