Vulnerability Disclosure Debate

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 fulldisclosure 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 securityholes 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-200304.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