idnits 2.17.1 draft-christey-wysopal-vuln-disclosure-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 303: '... 1) The Vendor SHOULD ensure that pr...' RFC 2119 keyword, line 313: '... 2) Customers SHOULD configure their...' RFC 2119 keyword, line 330: '...curity Community SHOULD track all know...' RFC 2119 keyword, line 337: '... 1) The Reporter SHOULD make a reasona...' RFC 2119 keyword, line 375: '... 1) The Vendor MUST make it as easy ...' (94 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2119' on line 104 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Steve Christey 3 INTERNET-DRAFT MITRE 4 Valid for six months Chris Wysopal 5 Category: Best Current Practice @stake, Inc. 6 February 2002 8 Responsible Vulnerability Disclosure Process 9 draft-christey-wysopal-vuln-disclosure-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2002). All Rights Reserved. 34 Abstract 36 New vulnerabilities in software and hardware products are discovered 37 and publicized on a daily basis. The disclosure of vulnerability 38 information has been a divisive topic for years. During the process 39 of disclosure, many vendors, security researchers, and other parties 40 follow a variety of unwritten or informal guidelines for how they 41 interact and share information. Some parties may be unaware of these 42 guidelines, or they may intentionally ignore them. This state of 43 affairs can make it difficult to achieve a satisfactory outcome for 44 everyone who uses or is affected by vulnerability information. 46 The purpose of this document is to describe best practices for a 47 responsible disclosure process that involves vulnerability reporters, 48 product vendors or maintainers, third parties, the security 49 community, and ultimately customers and users. 51 Table of Contents 53 1 Introduction and Purpose ....................................... 3 54 1.1 Background ................................................... 3 55 1.2 Major Roles in Disclosure .................................... 3 56 1.3 Motivations .................................................. 4 57 1.4 Goals of Responsible Disclosure .............................. 5 58 2 Phases of Responsible Disclosure ............................... 6 59 3 Responsibilities in the Phases of Vulnerability Disclosure ..... 7 60 3.1 Latent Flaw .................................................. 7 61 3.2 Discovery .................................................... 7 62 3.3 Notification Phase: Initial Notification ..................... 8 63 3.3.1 Vendor Responsibilities .................................... 8 64 3.3.2 Reporter Responsibilities .................................. 9 65 3.4 Notification Phase: Vendor Receipt .......................... 11 66 3.4.1 Vendor Responsibilities ................................... 11 67 3.5 Validation Phase ............................................ 11 68 3.5.1 Vendor Responsibilities ................................... 11 69 3.5.2 Reporter Responsibilities ................................. 13 70 3.5.3 Coordinator Responsibilities .............................. 14 71 3.6 Resolution Phase ............................................ 14 72 3.6.1 Vendor Responsibilities ................................... 14 73 3.6.2 Reporter Responsibilities ................................. 15 74 3.7 Release Phase ............................................... 16 75 3.7.1 Vendor Responsibilities ................................... 16 76 3.7.2 Reporter Responsibilities ................................. 18 77 3.7.3 Coordinator Responsibilities .............................. 18 78 3.7.4 Customer Responsibilities ................................. 19 79 3.7.5 Security Community Responsibilities ....................... 19 80 3.8 Follow-Up Phase ............................................. 20 81 4 Policy Publication ............................................ 20 82 4.1 Vendor Policy ............................................... 20 83 4.2 Reporter Policy ............................................. 20 84 4.3 Coordinator Policy .......................................... 21 85 5 References .................................................... 21 86 5.1 Disclosure Policies ......................................... 21 87 5.2 Commentary on Disclosure Details ............................ 21 88 5.3 Commentary on Disclosure Process ............................ 22 89 5.4 Commentary on Advisories .................................... 24 90 5.5 Commentary on Vendor Accessibility .......................... 24 91 5.6 Discovery of Issues in the Wild ............................. 25 92 5.7 Researcher Credibility and Vulnerability Reproduction ....... 26 93 5.8 Miscellaneous ............................................... 26 94 6 Acknowledgements .............................................. 26 95 7 Security Considerations ....................................... 26 96 8 Authors' Addresses ............................................ 27 97 9 Full Copyright Statement ...................................... 27 99 Document Conventions 101 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 102 and "MAY" in this document are to be interpreted as described in "Key 103 words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 105 1 Introduction and Purpose 107 This document provides guidance and recommendations for the community 108 of developers, vendors, end users, researchers and security 109 professionals who wish to perform responsible vulnerability 110 disclosure within the information technology arena. For purposes of 111 this document, the term "responsible" refers to the recognition of a 112 formal, repeatable process for the reporting, evaluation, resolution 113 and publication of vulnerability information. "Vulnerability" refers 114 to any bug, flaw, behavior, output, outcome or event within an 115 application, system, device, or service that could lead to increased 116 risk or security exploit. For purposes of this document, we have 117 standardized on the term "product" to encompass the full suite of 118 products that are addressed by this document. 120 1.1 Background 122 Vulnerabilities are an inherent and unfortunate part of the design 123 and development process. Vulnerability detection may occur during 124 any phase of the product lifecycle, to include design, development, 125 testing, implementation or operation. Ideally, vulnerabilities are 126 largely prevented through a design process that considers security. 127 However, due to a variety of reasons, many vulnerabilities are 128 detected after a product is implemented in an operational environment 129 and supporting customer objectives. A variety of legislative and 130 social issues directly influences the process for vulnerability 131 research, detection and response. Developers, customers and the 132 security community all have divergent perspectives on the impact of 133 vulnerabilities. Currently, vulnerability release is inconsistent 134 and largely driven from the perspective of the party who has the 135 greatest ability to control the process. In an effort to create a 136 common framework by which objectives are met to the benefit of all 137 parties, this document communicates a formal, repeatable process for 138 addressing vulnerability disclosure in a responsible manner. This 139 document provides a means to address the common goal of providing 140 more secure products while reducing the risk to customers. 142 1.2 Major Roles in Disclosure 144 Several types of individuals or organizations may play a role in the 145 process of vulnerability disclosure. These roles may overlap. 147 A Vendor is an individual or organization who provides, develops, or 148 maintains software, hardware, or services, possibly for free. 150 A Customer is the end user of the software, hardware, or service that 151 may be affected by the vulnerability. 153 A Reporter is the individual or organization that informs (or 154 attempts to inform) the Vendor of the vulnerability. Note that the 155 Reporter may not have been the initial discoverer of the problem. 157 A Coordinator is an individual or organization who works with the 158 Reporter and the Vendor to analyze and address the vulnerability. 159 Coordinators are often well-known third parties. Coordinators may 160 have resources, credibility, or working relationships that exceed 161 those of the reporter or vendors. Coordinators may serve as proxies 162 for reporters, help to verify the reporter's claims, resolve 163 conflicts, and work with all parties to resolve the vulnerability in 164 a satisfactory manner. Note: while Coordinators can facilitate the 165 responsible disclosure process for a vulnerability, the use of 166 Coordinators by other parties is not a requirement. 168 The Security Community includes individuals or organizations whose 169 primary goals include improving overall information technology 170 security. The community includes security administrators and 171 analysts, system administrators who are responsible for the security 172 of their systems, commercial or non-profit organizations who provide 173 security-related products or services, researchers and academics, 174 informal groups, and individuals. 176 1.3 Motivations 178 Individuals and organizations have a wide variety of motivations 179 (some in direct conflict with each other) that make the disclosure 180 process more complex. 182 Vendors may have one or more of the following motivations. Some 183 vendors believe that public notification may help their customers 184 address vulnerabilities, at the possible cost of negative publicity. 185 Some vendors may be unresponsive, or secretly fix vulnerabilities, 186 for fear of negative publicity. Some vendors may not have the 187 technical skills to understand the nature of the vulnerability and 188 the risk that it poses. 190 Customers often wish to have secure products, but security features 191 can make it more difficult to use those products. Many customers do 192 not care about the nature of the vulnerability. However, there is a 193 small percentage of customers for whom vulnerability information 194 plays a critical role in their usage of products. Some vendors may 195 be customers of other vendors. 197 Reporters have a variety of motivations. Because reporters are often 198 the means through which vulnerability information is communicated, 199 they have a major impact on how the disclosure process is followed. 200 Reporters may be motivated by altruism ("to make computers more 201 secure"), recognition or fame, marketing to highlight technical 202 skills (for individuals as well as companies), forcing unresponsive 203 vendors to address a vulnerability, curiosity or the challenge of 204 vulnerability analysis, or malicious intent to damage the reputations 205 of specific vendors, wreak havoc, or cause financial damage to 206 customers. The vague goals of altruism are often open to different 207 interpretations by different reporters. Reporters may be 208 inexperienced, malicious, or have insufficient resources to follow 209 the full process of disclosure. Reporters are seldom compensated for 210 their important role in enhancing Internet security. 212 The motivations for members of the security community may vary 213 depending on the specific tasks that are being undertaken by the 214 members. Community members may have motivations that include those 215 of vendors, customers, and/or reporters. In addition, members of the 216 security community may wish to track trends in vulnerabilities, 217 identify new types of vulnerabilities, or design new products and 218 processes to reduce the impact of vulnerabilities. 220 Coordinators are often members of the security community, and as such 221 may share the same motivations. Coordinators may also be required by 222 their mission or contract to perform this role. 224 1.4 Goals of Responsible Disclosure 226 The goals of responsible disclosure include: 228 1) Ensure that vulnerabilities can be identified and eliminated 229 effectively and efficiently for all parties. 231 2) Minimize the risk to customers from vulnerabilities that could 232 allow damage to their systems. 234 3) Provide customers with sufficient information for them to evaluate 235 the level of security in vendors' products. 237 4) Provide the security community with the information necessary to 238 develop tools and methods for identifying, managing, and reducing the 239 risks of vulnerabilities in information technology. 241 5) Minimize the amount of time and resources required to manage 242 vulnerability information. 244 6) Facilitate long-term research and development of techniques, 245 products, and processes for avoiding or mitigating vulnerabilities. 247 7) Minimize the amount of antagonism that often exists between 248 parties as a result of different assumptions and expectations, due to 249 the lack of consistent and explicit disclosure practices. 251 2 Phases of Responsible Disclosure 253 Following are the basic phases of the responsible vulnerability 254 disclosure process. Some of these phases may be bypassed in specific 255 situations with agreement across all parties. In other cases, one or 256 more parties may not be responsible, skipping some phases. 258 1) Latent Flaw. A flaw is introduced into a product during its 259 design, specification, development, installation, or default 260 configuration. 262 2) Discovery. One or more individuals or organizations discover the 263 flaw through casual evaluation, by accident, or as a result of 264 focused analysis and testing. In some cases, knowledge of the flaw 265 may be kept within a particular group. A vulnerability report or an 266 exploit program may be discovered "in the wild," i.e., in use by 267 malicious attackers or made available for use and distribution. 269 3) Notification. A reporter or coordinator notifies the vendor of 270 the vulnerability ("Initial Notification"). In turn, the vendor 271 provides the reporter or coordinator with assurances that the 272 notification was received ("Vendor Receipt"). 274 4) Validation. The vendor or other parties verify and validate the 275 reporter's claims ("Reproduction"). 277 5) Resolution. The vendor and other parties also try to identify 278 where the flaw resides ("Diagnosis"). The vendor develops a patch or 279 workaround that eliminates or reduces the risk of the vulnerability 280 ("Fix Development"). The patch is then tested by other parties (such 281 as reporter or coordinator) to ensure that the flaw has been 282 corrected ("Patch Testing"). 284 6) Release. The vendor, coordinator, and/or reporter release the 285 information about the vulnerability, along with its resolution. The 286 vendor may initially release this information to its customers and 287 other organizations with which it may have special relationships 288 ("Limited release"). The vendor or other parties may then release 289 the information - possibly with additional details - to the security 290 community. 292 7) Follow-up. The vendor, customer, coordinator, reporter, or 293 security community may conduct additional analysis of the 294 vulnerability or the quality of its resolution. 296 3 Responsibilities in the Phases of Vulnerability Disclosure 298 3.1 Latent Flaw 300 The following recommendations identify how most latent flaws can be 301 avoided. 303 1) The Vendor SHOULD ensure that programmers, designers, and testers 304 are knowledgeable about common flaws in the design and implementation 305 of products. 307 Rationale: Some classes of vulnerabilities are well-known and can be 308 easily exploited using repeatable techniques. Educated programmers, 309 designers, and testers can identify and eliminate vulnerabilities 310 before the product is provided to customers, or prevent their 311 introduction into the product in the first place. 313 2) Customers SHOULD configure their products and systems in ways that 314 eliminate latent flaws or reduce the impact of latent flaws, 315 including (1) removing default services that are not necessary for 316 the operation of the affected systems, (2) limiting necessary 317 services only to networks or systems that require access, (3) using 318 the minimal amount of access and privileges necessary for proper 319 functioning of the products, and (4) using security features of the 320 product or operating system that reduce the chance that a flaw can be 321 successfully exploited. 323 Rationale: Many computer intrusions involve the exploitation of 324 vulnerabilities in network services that are unnecessary for typical 325 operating environments. In some cases, system configuration can 326 reduce the overall risk of vulnerabilities (known and unknown). For 327 example, the Code Red and Nimda worms of 2001 were largely successful 328 because of these factors. 330 3) The Security Community SHOULD track all known vulnerabilities to 331 identify new classes of vulnerabilities, educate the public about 332 these types of vulnerabilities, and find ways to detect or prevent 333 them in the development, testing, and deployment of products. 335 3.2 Discovery 337 1) The Reporter SHOULD make a reasonable effort to ensure that: - the 338 vulnerability is real - the process of getting the product into a 339 known exploitable state is repeatable - the vulnerability has not 340 already been reported by the vendor or well-established vulnerability 341 information sources 343 Rationale: Some vulnerabilities are re-discovered after they have 344 already been fixed, or the reporter has introduced the problem due to 345 misconfiguration, or the reporter identifies the symptoms of the 346 vulnerability without determining the cause. If the reporter ensures 347 that the problem is new and real, then the reporter will will avoid 348 unnecessarily consuming the time and resources spent by vendors and 349 other parties in investigating the problem. 351 Note: in some cases, a reporter may not be able to make a reasonable 352 effort due to limitations of time, resources, access to the product, 353 or expertise. In some cases, the problem may only appear 354 intermittently, or the product is only temporarily accessible to the 355 reporter (e.g., when the reporter is a consultant who discovers the 356 problem in products that a customer uses). In other cases, the 357 reporter may discover information about the vulnerability without 358 having any access to the product. 360 Note: in some cases, the reporter may be able to coerce the product 361 into a state that is known to be exploitable, without creating a 362 fully working exploit program (e.g., a buffer overflow with a long 363 string of 'A' characters may produce a result that shows that the 364 instruction pointer has been overwritten). This is considered a 365 reasonable effort. 367 3.3 Notification Phase: Initial Notification 369 To facilitate the disclosure process, Vendors need to be accessible 370 to Reporters, and Reporters need to find and use the appropriate 371 communication channels for notifying Vendors. 373 3.3.1 Vendor Responsibilities 375 1) The Vendor MUST make it as easy as possible for Reporters, 376 Coordinators, Customers, and the Security Community to notify the 377 Vendor of vulnerabilities. 379 Rationale: It is often difficult for reporters or other parties to 380 notify vendors of vulnerabilities, especially if the reporters are 381 not customers. This may cause the parties to bypass other phases of 382 the disclosure process, or adopt a policy that avoids vendor 383 notification because of previous bad experiences with vendors. 385 2) The Vendor SHOULD establish a Security Response Capability (SRC) 386 that consists of one or more individuals or groups that are 387 responsible for responding to vulnerability reports, verifying 388 vulnerabilities, releasing bulletins, etc. 390 3) The Vendor SHOULD ensure that its staff knows how to recognize a 391 reported security issue and direct it to the Security Response 392 Capability. This recommendation applies to staff who provide support 393 online, over the telephone, in person, or through some other means by 394 which reporters may interact with the Vendor. 396 4) If the Vendor can control the e-mail addresses that it uses (e.g., 397 it has its own domain name), then the Vendor SHOULD define and 398 publish the "secalert" alias for use in vulnerability notification. 400 Rationale: Currently, Vendors use a variety of aliases for 401 notification, including "security-alert," "security," and "support." 402 Some Vendors may use the "security" alias for physical security 403 facilities. The "security" alias is also defined in RFC2142 for use 404 in incident handling. The "security-alert" alias is longer than 8 405 characters and contains a dash, which could make it more difficult to 406 use or locate in search engines. The "secalert" alias is not 407 commonly used at this time, and as such it does not have the types of 408 issues that some commonly-used aliases have. 410 Note: smaller vendors may not be able to control which e-mail 411 addresses they use. 413 5) If the Vendor operates a web site or other means of distributing 414 information regarding its product, then the Vendor SHOULD create and 415 publish a "security" page or folder that identifies how vulnerability 416 reports should be made. The Vendor SHOULD make this page easy to 417 find from other locations, such as a separate contact page or index. 419 6) The Vendor MUST provide a facility for individuals or 420 organizations who are not Customers to report vulnerabilities. The 421 Vendor SHOULD NOT require (1) an active technical support number, (2) 422 telephone access that is not toll-free, or (3) user registration for 423 a web site or other facility that would be used for reporting. 425 Rationale: As described earlier, some reporters or coordinators are 426 not necessarily customers of the Vendor. If the Vendor is not 427 accessible to them, then they will be more likely to bypass other 428 aspects of this process. 430 7) The Vendor SHOULD recognize that inexperienced or malicious 431 reporters may not use proper notification, and define its own 432 procedures for handling such cases. 434 3.3.2 Reporter Responsibilities 436 1) The Reporter SHOULD make reasonable efforts to use the appropriate 437 channels for notifying the Vendor of the vulnerability: 439 (a) The Reporter SHOULD attempt to notify the vendor through the 440 channels described in this section. 442 (b) If the Vendor is not accessible through those channels, then the 443 Reporter MAY attempt to contact the vendor through technical 444 support. 446 Note: in some cases, a reporter may not be able to make a reasonable 447 effort due to time limitations, lack of proper access to the vendor, 448 inexperience, expense, prohibitions by the reporter's own 449 organization, or the reporter does not meet some criteria for 450 notification (e.g., a support contract number). 452 2) If the Reporter is unable to notify the Vendor, then the Reporter 453 SHOULD ask a Coordinator to notify the Vendor. The Reporter SHOULD 454 provide the Coordinator with a list of contacts or mechanisms that 455 were used to attempt to notify the Vendor. 457 Rationale: a Coordinator may appear more credible than the Reporter, 458 or have a previously established relationship with the Vendor. The 459 Reporter may be prohibited from disclosing the vulnerability directly 460 to the Vendor. 462 Note: the Coordinator will not necessarily have a different way of 463 reaching the Vendor than the Reporter does. 465 3) The Reporter and/or Coordinator SHOULD record the date of 466 notification. 468 Rationale: This helps Customers, Reporters, Coordinators, and the 469 Security Community track how long it takes for a Vendor to resolve a 470 vulnerability after the initial notification. 472 4) The Reporter SHOULD provide the Vendor, and the Coordinator (if 473 any), with all known details of the issue, including any programs, 474 scripts, or pseudo-code that would allow the Vendor to reproduce 475 and/or confirm the vulnerability. 477 Rationale: such details make it easier for the Vendor and Coordinator 478 to reproduce and diagnose the vulnerability, which then allows the 479 Vendor to identify or develop a resolution more quickly. 481 Note: some vulnerabilities may be theoretical or not well-understood 482 in this phase of the disclosure process, and the Reporter may not 483 have developed programs that exploit the problem. In other cases, 484 the Reporter may be using proprietary programs to demonstrate the 485 vulnerability. 487 3.4 Notification Phase: Vendor Receipt 489 3.4.1 Vendor Responsibilities 491 1) The Vendor MUST notify the Reporter and involved Coordinators that 492 the Vendor has received the notification. This Receipt does not 493 necessarily imply that the Vendor has researched or reproduced the 494 vulnerability, only that the Vendor is aware of the notification. 496 Rationale: if the Vendor does not respond, then the Reporter or 497 Coordinator may not be sure if the Vendor is truly aware of the 498 reported vulnerability, and/or if the Vendor intends to resolve the 499 vulnerability. This often causes Reporters or Coordinators to bypass 500 later phases of the disclosure process in order to warn customers of 501 the risks to their systems. 503 2) The Vendor MUST provide the Reporter and involved Coordinators 504 with a Receipt within 7 days. 506 Rationale: Other time frames (such as 5 business days) were 507 considered but deemed unworkable due to international issues (e.g., 508 "work weeks" may fall on different days in different countries, there 509 are different national or religious holidays). Defining a time frame 510 relative to the Vendor or Reporter could not work without some form 511 of communication between both parties. 513 Note: small but responsible Vendors or individuals may not be able to 514 provide this degree of responsiveness, especially during vacation 515 periods. Reporters and Coordinators SHOULD take this into account 516 during the notification phase. Small, responsible Vendors SHOULD 517 post some clear notification when it is known that such delays will 518 occur. 520 3) If the Vendor's receipt message is automatically generated, then 521 it SHOULD include a time period or date by which an individual (or 522 the Security Response Capability) will provide follow-up on the 523 reported vulnerability. The time period SHOULD NOT exceed 10 days. 525 4) Within 10 days of initial notification, the Vendor's Security 526 Response Capability SHOULD provide a clear response to the Reporter 527 and any involved Coordinators. 529 3.5 Validation Phase 531 3.5.1 Vendor Responsibilities 533 1) If the vulnerability is found in a supported product, the Vendor 534 MUST either (1) reproduce the vulnerability, (2) determine if there 535 is enough evidence for the existence of the vulnerability when it 536 cannot be reproduced, (3) determine if the vulnerability is already 537 known (and possibly resolved), or (4) work with the Reporter to 538 determine if the vulnerability is related to the specific environment 539 in which it was discovered (including configuration errors or 540 interactions with other products). 542 2) If the vulnerability is found in an unsupported or discontinued 543 product, the Vendor MAY refuse to validate the vulnerability. 544 However, the Vendor MUST ensure that the reported vulnerability does 545 not exist in supported product versions or other supported products 546 based on the vulnerable product. 548 3) The Vendor SHOULD NOT assume that the risk or impact of the 549 vulnerability is limited to what has been identified by the Reporter 550 or involved Coordinator. 552 Rationale: The Reporter or involved Coordinator may not have 553 sufficient experience or time to identify the full scope of the 554 problem. Sometimes, a theoretical vulnerability is later found to be 555 more easily exploitable as a result of follow-on analysis or the 556 creation of a tool. For example, it may be easy for a Reporter to 557 find evidence of a buffer overflow vulnerability by sending a long 558 argument that causes a product to crash. It is an indicator that a 559 carefully crafted program could be used to execute arbitrary code. 560 The Reporter and Vendor may not have the skills or resources to 561 create such a program, but such a program could be created in the 562 future. 564 4) The Vendor SHOULD examine its product to ensure that it is free of 565 other problems that are similar to the reported vulnerability. 567 Rationale: some Vendors reproduce and resolve the specific issue that 568 is identified by the Reporter without extending their analysis to see 569 if similar mistakes were made elsewhere in the product. The 570 Reporter, others in the Security Community, or hackers may conduct 571 follow-on research to find these other vulnerabilities. This can 572 result in a cycle in which vulnerabilities are discovered and patched 573 so often that it becomes difficult for customers to manage the volume 574 of resolutions that they need to apply. 576 5) The Vendor MUST consult with the Reporter and involved 577 Coordinators when more information or analysis is needed. 579 6) The Vendor SHOULD provide status updates to the Reporter and any 580 involved Coordinators every 7 days. The Vendor MAY negotiate with 581 the parties for less frequent updates. 583 7) The Vendor MUST notify the Reporter and any involved Coordinators 584 when the Vendor is able to reproduce the vulnerability. 586 8) The Vendor SHOULD attempt to resolve the vulnerability within 30 587 days of initial notification. 589 9) If the Vendor cannot resolve the vulnerability within 30 days, 590 then the Vendor MUST provide the Reporter and involved Coordinators 591 with specific reasons why the vulnerability cannot be resolved. 593 10) If the Vendor is aware of other vendors that share the same 594 codebase as the affected product, then the Vendor MUST either (1) 595 notify those vendors, or (2) notify a Coordinator that other Vendors 596 may be affected by the reported vulnerability. 598 3.5.2 Reporter Responsibilities 600 1) The Reporter SHOULD work with the Vendor in a timely fashion to 601 explain the vulnerability and conduct further analysis. 603 Rationale: if a problem is sufficiently complex or only appears in a 604 portion of deployed systems, then the Vendor may not be able to 605 reproduce the issue. In other cases, the Vendor may not understand 606 the problem. If the Reporter is slow to respond, then this can 607 extend the time window during which Customers are at risk. 609 2) If the Vendor does not understand the nature, risk, or resolution 610 of the vulnerability, then the Reporter or involved Coordinators 611 SHOULD provide the Vendor with resources that help to explain the 612 vulnerability. 614 Note: Some Vendors may require - or insist - upon extensive 615 consultation to identify the vulnerability. Reporters and 616 Coordinators may not have the time or resources to provide such 617 assistance. 619 3) If the Reporter does not have the time or resources to conduct 620 such analysis, then the Reporter SHOULD notify the Vendor and suggest 621 alternate contacts (such as Coordinators) who may be able to assist 622 the Vendor. The Reporter SHOULD NOT attempt to bypass later phases. 624 4) If the Reporter finds that the Reporter is in error, then the 625 Reporter SHOULD notify the Vendor and involved Coordinators. 627 Rationale: if a Reporter does not perform this notification, then the 628 Vendors or Coordinators may continue to spend unnecessary resources 629 on further analysis of the issue. 631 5) The Reporter SHOULD grant time extensions to the Vendor if there 632 is evidence that the Vendor is acting in good faith to resolve the 633 vulnerability. 635 6) If the Vendor is unresponsive or disagrees with the Reporter's 636 findings, then the Reporter SHOULD involve a Coordinator. 638 3.5.3 Coordinator Responsibilities 640 1) The Coordinator MUST attempt to resolve any conflicts or technical 641 disagreements that arise between the Reporter and the Vendor. 643 2) If a Vendor is unresponsive or does not appear to be acting in 644 good faith to resolve the vulnerability, then the Coordinator SHOULD 645 attempt to convince the Vendor to follow the proper process. 647 3) If a Reporter is unresponsive or does not appear to be acting in 648 good faith to resolve the vulnerability, then the Coordinator SHOULD 649 attempt to convince the Reporter to follow the proper process. 651 4) The Coordinator SHOULD work with the Vendor and Reporter to 652 determine if other Vendors are affected by the same problem. 654 5) The Coordinator SHOULD work with the Vendor and Reporter to 655 identify time extensions (if any) that are acceptable to all 656 parties. 658 3.6 Resolution Phase 660 The "Resolution" of a vulnerability involves action regarding one or 661 more of the following: 663 - patch creation 664 - recommendation of configuration change 665 - design change 666 - workaround 667 - no action 669 If the Vendor does not participate or is unresponsive, then the 670 Reporter and Coordinator might not be able to create a patch or 671 change the design of the product. 673 3.6.1 Vendor Responsibilities 675 1) The Vendor MUST identify the fundamental nature of the flaw within 676 the source code or in the design of the product ("Diagnosis"). 678 2) The Vendor MUST either (1) provide a patch, configuration change, 679 or workaround that appropriately reduces or eliminates the risk of 680 the vulnerability ("Fix Development"), or (2) provide the Reporter 681 and involved Coordinators with specific reasons for its inaction. 683 3) The Vendor SHOULD request time extensions from the Reporter and 684 involved Coordinators when necessary. 686 4) The Vendor SHOULD test the patches, configuration changes, and 687 workarounds sufficiently to ensure that either (1) they do not 688 adversely affect the operation of the product, or (2) it is clear 689 which conditions may adversely affect the operation of the product. 691 Rationale: Vendors may be pressured to quickly resolve 692 vulnerabilities without sufficient testing, especially when Reporters 693 have bypassed the Notification or Validation phases. As a result, 694 the resolution may adversely affect more systems than necessary. 696 5) The Vendor MUST provide the Reporter and involved Coordinators 697 with all known configuration changes or workarounds that address the 698 vulnerability ("Fix Development"). 700 6) The Vendor SHOULD provide the Reporter and involved Coordinators 701 with any patches ("Patch Testing"). 703 Rationale: this helps the Reporter and Coordinator to confirm that 704 the vulnerability has been reduced or eliminated. 706 Note: the Vendor's business model may require that only supported 707 Customers can have access to a patch, which could exclude Reporters 708 or Coordinators. Such Vendors should recognize that this practice 709 may result in an incomplete patch that does not address the 710 vulnerability in question. 712 7) If the Reporter is unresponsive or uncooperative, or a dispute 713 arises, then the Vendor SHOULD work with a Coordinator to identify 714 the best available resolution for the vulnerability. 716 3.6.2 Reporter Responsibilities 718 1) The Reporter SHOULD recognize that it may be difficult for a 719 Vendor to resolve a vulnerability within 30 days if (1) the problem 720 is related to insecure design, (2) the Vendor has a diverse set of 721 hardware, operating systems, and/or product versions to support, or 722 (3) the Vendor is not skilled in security. 724 2) The Reporter SHOULD grant time extensions to the Vendor if the 725 Vendor is acting in good faith to resolve the vulnerability. 727 3) If the Vendor is unresponsive or uncooperative, or a dispute 728 arises, then the Reporter SHOULD work with a Coordinator to identify 729 the best available resolution for the vulnerability. 731 3.7 Release Phase 733 3.7.1 Vendor Responsibilities 735 1) The Vendor SHOULD work with the Reporter and involved Coordinators 736 to arrange a date after which the vulnerability information may be 737 released. 739 2) The Vendor MAY ask the Reporter and Coordinator to allow a "Grace 740 Period" up to 30 days, during which the Reporter and Coordinator do 741 not release details of the vulnerability that could make it easier 742 for hackers to create exploit programs. 744 Rationale: a grace period provides Customers with a time period in 745 which they can fix their systems. During this time, the lack of 746 details may make it more difficult or resource-intensive for 747 attackers to determine the nature of the vulnerability and craft an 748 exploit. However, some security-aware Customers desire such details 749 so that they can better decide whether the resolution of the 750 vulnerability is appropriate for their environment. In addition, 751 some members of the Security Community desire such details in order 752 to (1) enhance tools or techniques to detect vulnerable systems on 753 Customer networks (such as vulnerability scanners), (2) enhance tools 754 or techniques to detect attempts to exploit vulnerabilities on 755 Customer networks (such as intrusion detection systems), (3) provide 756 databases or other information that Customers use to identify and 757 prioritize vulnerabilities that may affect the Customer's enterprise, 758 and (4) perform research and trend analysis. 760 3) If the Reporter has not properly followed the process and publicly 761 announces the vulnerability, then the Vendor SHOULD post its 762 awareness of the vulnerability, and the Vendor's progress in its 763 resolution, to appropriate forums. 765 Rationale: this allows Customers and the Security Community to know 766 that the Vendor is aware of the problem and working to resolve it. 768 Note: some Vendors may not wish to acknowledge such vulnerabilities 769 until a patch is available. 771 4) If a Reporter has properly followed the process, then the Vendor 772 MUST provide credit to that reporter. 774 5) If a Coordinator has properly followed the process, then the 775 Vendor SHOULD provide credit to the Coordinator. 777 6) If a Reporter has not properly followed the process and publicly 778 announces the vulnerability, then the Vendor MAY provide credit to 779 the reporter. 781 Rationale: Some people believe that even if a reporter has not 782 followed the procedures properly, the reporter has still provided 783 valuable information that is useful to the Vendor, Customers, 784 Coordinators, and the Security Community, and academic integrity 785 would dictate that reporters should be credited. However, since 786 credit is a motivation for some reporters, others believe that 787 irresponsible reporters should not be encouraged to bypass the 788 process and still get credit. 790 7) The Vendor MUST NOT assume that the lack of vulnerability details 791 will prevent the creation of an exploit. 793 Rationale: If the Vendor provides source code for the product, then 794 any entity who has access to the product could easily determine the 795 specific locations of the vulnerability and identify possible attack 796 vectors that reach the vulnerable code. If the Vendor does not 797 provide source code, then any entity who has access to a patch could 798 use reverse engineering techniques to determine how the code was 799 changed, then infer the nature of the vulnerability. 801 8) The Vendor SHOULD cryptographically sign all patches using a 802 method that is commonly accessible on the platforms for the Vendor's 803 product. The Vendor should clearly advertise its cryptographic key 804 and provide cryptographic checksums for its patches. 806 Rationale: This increases the assurance that the patches from the 807 Vendor are authentic. 809 9) The Vendor SHOULD provide an easily accessible mechanism for 810 Customers and the Security Community to obtain all security 811 advisories, such as a web page. The most recent advisory SHOULD be 812 listed first. 814 10) The Vendor SHOULD provide a mechanism for notifying Customers and 815 the Security Community when new advisories are published. 817 11) The Vendor SHOULD provide a means for the Security Community to 818 identify which reported vulnerabilities are genuine, but are not 819 regarded by the Vendor as important enough to merit a security 820 advisory. 822 Rationale: Vendors are often unwilling to release security advisories 823 unless the security issue is critical for its Customers. This can 824 reduce operating expenses for the Vendor and most Customers. 825 However, some members of the Security Community, and some Customers, 826 also prefer to protect themselves against less serious 827 vulnerabilities. If a Vendor does not at least indicate to its 828 security-aware Customers that a security-related resolution is 829 available, then those Customers may remain at risk for 830 vulnerabilities that they would otherwise wish to resolve. 832 12) The Vendor SHOULD provide an easily accessible indicator that 833 allows a Customer to determine if the resolution has been applied to 834 a system, e.g., by modifying the product's version number or 835 providing the Customer with a tool that identifies the resolutions 836 that have been applied to a product. 838 3.7.2 Reporter Responsibilities 840 1) The Reporter SHOULD work with the Vendor and involved Coordinators 841 to arrange a date after which the vulnerability information may be 842 released. 844 2) If the Vendor has not resolved the vulnerability within a time 845 frame that is allowed by this process, then the Reporter SHOULD work 846 with a Coordinator to announce the vulnerability to Customers and the 847 Security Community. 849 3) If another reporter has not properly followed the process and 850 publicly announced the vulnerability, then the Reporter MAY announce 851 that the Reporter was responsibly following the disclosure process 852 with the Vendor and involved Coordinators. 854 4) If a Vendor requests a Grace Period, then the Reporter SHOULD 855 follow the Grace Period before releasing details of the 856 vulnerability. 858 5) After the Grace Period, the Reporter MAY release additional 859 details. The Reporter SHOULD carefully consider how much detail is 860 needed by Customers and the Security Community. 862 Note: in some cases, the nature of the vulnerability could make it 863 difficult or impossible to release vulnerability details that do not 864 allow someone to exploit the vulnerability. 866 6) The Reporter SHOULD provide credit to any Vendor and/or 867 Coordinator who has followed the process. 869 3.7.3 Coordinator Responsibilities 871 1) The Coordinator SHOULD work with the Vendor and Reporter to 872 arrange a date after which the vulnerability information may be 873 released. 875 2) If the Vendor requests a Grace Period, the Coordinator SHOULD 876 follow the Grace Period and encourage the Reporter to follow the 877 Grace Period. 879 3) The Coordinator SHOULD provide credit to any Vendor and/or 880 Reporter who properly follows the process. 882 4) The Coordinator MAY provide credit to a reporter who has not 883 properly followed the process. 885 3.7.4 Customer Responsibilities 887 1) The Customer MUST NOT assume that the lack of details will prevent 888 the creation of an exploit. 890 2) If the Vendor has released information regarding the 891 vulnerability, then the Customer SHOULD assume that the information 892 is credible. The Customer SHOULD NOT require that the vulnerability 893 be demonstrated before applying the resolution. 895 3) If the Vendor has not released such information, but a 896 well-established Reporter or Coordinator has, then the Customer 897 SHOULD assume that the information is credible. The Customer SHOULD 898 NOT require that the vulnerability be demonstrated before applying 899 the resolution. 901 4) If vulnerability information has been released and a Grace Period 902 exists, then the Customer SHOULD apply the resolution to its systems 903 during the Grace Period. 905 5) Where possible, the Customer SHOULD test any patches, 906 configuration changes, or workarounds on test systems before making 907 the changes in an operational environment. 909 6) The Customer SHOULD inform the Vendor and the Security Community 910 if a patch, configuration change, or workaround does not appear to 911 work properly. 913 7) The Customer SHOULD give preference to products whose Vendors 914 follow responsible disclosure practices. 916 3.7.5 Security Community Responsibilities 918 1) The Security Community SHOULD publicly recognize all Vendors, 919 Reporters, and Coordinators who follow responsible vulnerability 920 disclosure. 922 2) The Security Community SHOULD adopt a set of terms that allows all 923 parties to describe the inherent risk or impact of a vulnerability 924 that can be interpreted in various environments, threat levels, and 925 policies. 927 Rationale: Customers have varying operational needs at different 928 levels of security, which can make it difficult to define a "one size 929 fits all" risk level for any vulnerability. Current terminology 930 often uses a "High, Medium, Low" breakdown, but there are no formal 931 definitions. As such, this terminology is used inconsistently, 932 partially because it is based on the perspective of the entity who is 933 using it. It is also insufficient to capture the complexity and 934 tradeoffs of vulnerabilities in today's environment. 936 3.8 Follow-Up Phase 938 1) The Vendor SHOULD clearly notify Customers and the Security 939 Community when a resolution is (a) faulty, or (b) revised. 941 2) The Vendor SHOULD NOT re-release the same advisory for newly 942 discovered, closely related vulnerabilities. 944 Rationale: The re-release of an advisory may not be noticed as well 945 by Customers, which could cause the Customers to believe that their 946 systems are secure because they applied the resolution that was 947 identified in the original advisory. 949 4 Policy Publication 951 4.1 Vendor Policy 953 A Vendor SHOULD publish a policy and procedures statement that 954 includes the following information: 956 1) Where it complies (and does not comply) with the process outlined 957 in this document. 959 2) The typical amount of time after notification that the Vendor 960 requires to produce a resolution. 962 3) The Grace Period, if any, that the Vendor wishes to observe. 964 4) How the Vendor determines whether a reported problem is serious 965 enough to merit a security advisory. 967 4.2 Reporter Policy 969 If a Reporter is a member of the Security Community and the Reporter 970 frequently finds new vulnerabilities, then the Reporter SHOULD 971 publish a policy and procedures statement that includes the following 972 information: 974 1) Where it complies (and does not comply) with the process outlined 975 in this document. 977 2) The maximum Grace Period that the Reporter is willing to follow. 979 4.3 Coordinator Policy 981 A Coordinator SHOULD publish a policy and procedures statement that 982 includes the following information: 984 1) Where the Coordinator complies (and does not comply) with the 985 process outlined in this document. 987 2) The maximum Grace Period that the Coordinator is willing to 988 follow. 990 5 References 992 Note: many of these references identify posted messages to 993 security-related mailing lists. These messages often resulted in 994 long threads that explore the related issues in more depth. 996 5.1 Disclosure Policies 998 RFPolicy 2.0 999 http://www.wiretrip.net/rfp/policy.html 1001 Bugtraq Frequently Asked Questions 1002 http://www.securityfocus.com/popups/forums/bugtraq/faq.shtml 1004 NTBugtraq Disclosure Policy 1005 http://ntbugtraq.ntadvice.com/default.asp?sid=1&pid=47&aid=48 1007 CERT/CC Vulnerability Disclosure Policy 1008 http://www.kb.cert.org/vuls/html/disclosure/ 1010 ACROS ASPR Notification and Publishing Policy 1011 http://www.acros.si/aspr_policy.html 1013 NMRC policy 1014 http://www.nmrc.org/advise/policy.txt 1016 @stake Security Advisory Disclosure Policy 1017 http://www.atstake.com/research/policy/index.html 1019 5.2 Commentary on Disclosure Details 1021 "Full Disclosure is a necessary evil" 1022 Elias Levy 1023 SecurityFocus web site 1024 August 16, 2001 1025 http://www.securityfocus.com/news/238 1026 "It's Time to End Information Anarchy" 1027 Scott Culp 1028 Microsoft web site 1029 October 2001 1030 http://www.microsoft.com/technet/columns/security/noarch.asp 1032 "Security in an Open Electronic Society" 1033 Elias Levy 1034 SecurityFocus web site 1035 October 21, 2001. 1036 http://www.securityfocus.com/news/270 1038 "Full Disclosure" 1039 Bruce Schneier 1040 Crypto-Gram Newsletter 1041 November 15, 2001 1042 http://www.counterpane.com/crypto-gram-0111.html#1 1044 "Script Kiddies Suck" 1045 Marcus Ranum 1046 Black Hat Briefings presentation 1047 July 2000 1048 http://web.ranum.com/usenix/blackhat-2000-keynote.mp3 1050 "The Network Police Blotter: The Slaughter of the Innocents" 1051 Marcus Ranum 1052 ;Login: magazine 1053 October 2000 1054 http://web.ranum.com/usenix/ranum_5_temp.pdf 1056 5.3 Commentary on Disclosure Process 1058 "Bugs in the Disclosure Process" 1059 Ivan Arce 1060 TISC Insight, Volume 3, Issue 3 1061 February 9, 2001 1062 http://tisc.corecom.com/newsletters/33.html 1064 "SUMMARY: Bug announcement rule of thumb." 1065 Bill Stout 1066 NTBugtraq mailing list 1067 August 13, 1998 1068 http://marc.theaimsgroup.com/?l=ntbugtraq&m=90310164223252&w=2 1069 "Microsoft admits IE security alert lapse" 1070 Wendy McAuliffe 1071 ZDNet 1072 November 19, 2001 1073 http://www.zdnet.com/filters/printerfriendly/ 1074 0,6061,2825716-2,00.html 1076 "RFP2K03: Contemplations on dvwssr.dll and its affects on life" 1077 Rain Forest Puppy 1078 Bugtraq mailing list 1079 April 20, 2000 1080 http://www.securityfocus.com/archive/1/56394 1082 "Xato Advisory: Win2k/XP Terminal Services IP Spoofing" 1083 Xato 1084 Bugtraq mailing list 1085 November 14, 2001 1086 http://www.securityfocus.com/archive/1/240248 1088 "Vulnerability Escrow (was: Extreme Hacking)" 1089 Crispin Cowan 1090 NFR Wizards mailing list 1091 July 7, 1999 1092 http://archives.neohapsis.com/archives/nfr-wizards/1999_2/0416.html 1094 "Can we afford full disclosure of security holes?" 1095 Richard M. Smith 1096 Bugtraq mailing list 1097 August 10, 2001 1098 http://www.securityfocus.com/archive/1/203499 1100 "Anti-Web 'Vulnerability' is a false alarm" 1101 Doug Hoyte 1102 Vuln-Dev mailing list 1103 December 1, 2001 1104 http://marc.theaimsgroup.com/?l=vuln-dev&m=100732828128718&w=2 1106 "Windows of Vulnerability: A Case Study Analysis" 1107 William A. Arbaugh, William L. Fithen, John McHugh 1108 IEEE Computer 1109 December 2000 1111 "Sun denies Unix flaw" 1112 John Geralds 1113 vnunet.com 1114 November 20, 2001 1115 http://www.vnunet.com/News/1126973 1116 "Open Response To Microsoft Security - RE: It's Time to End 1117 Information Anarchy" 1118 Steve Manzuik 1119 Vuln-Dev mailing list 1120 October 17, 2001 1121 http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0195.html 1123 "A Step Towards Information Anarchy: A Call To Arms" 1124 hellNbak 1125 Nomad Mobile Research Center 1126 November 2, 2001 1127 http://www.nmrc.org/InfoAnarchy/InfoAnarchy.htm 1129 "To Disclose or Not to Disclose, That Is the Question" 1130 Mark Joseph Edwards 1131 Windows 2000 Magazine 1132 June 27, 2001 1133 http://www.windowsitsecurity.com/Articles/Index.cfm?ArticleID=21618 1135 "Towards a responsible vulnerability process" 1136 David LeBlanc 1137 NTBugtraq mailing list 1138 November 3, 2001 1139 http://archives.neohapsis.com/archives/ntbugtraq/2001-q4/0097.html 1141 5.4 Commentary on Advisories 1143 "Writing security advisories" 1144 Kurt Seifried 1145 September 10, 2001 1146 http://www.seifried.org/security/articles/ 1147 20010910-writing-security-advisories.html 1149 "Xato commentary on MS security bulletins" 1150 Xato 1151 Bugtraq mailing list 1152 December 7, 2000 1153 http://marc.theaimsgroup.com/?l=bugtraq&m=97626305317046&w=2 1155 5.5 Commentary on Vendor Accessibility 1157 "Getting to the Third Wave of Security Responsiveness" 1158 Scott Culp 1159 January 2001 1160 http://www.microsoft.com/technet/columns/security/thrdwave.asp 1161 "An informal analysis of vendor acknowledgement of vulnerabilities" 1162 Steve Christey, Barbara Pease 1163 Bugtraq mailing list 1164 March 11, 2001 1165 http://marc.theaimsgroup.com/?l=bugtraq&m=98438570915835&w=2 1167 "Shockwave Flash buffer overflow" 1168 Neal Krawetz 1169 Bugtraq mailing list 1170 December 29, 2000 1171 http://marc.theaimsgroup.com/?l=bugtraq&m=97845942432045&w=2 1173 "Re: Shockwave Flash buffer overflow" 1174 Peter Santangeli 1175 Bugtraq mailing list 1176 January 5, 2001 1177 http://marc.theaimsgroup.com/?l=bugtraq&m=97897439808223&w=2 1179 "Re: SafeWord Agent for SSH (secure shell) vulnerability" 1180 Leif Nixon 1181 Bugtraq mailing list 1182 November 29, 2001 1183 http://marc.theaimsgroup.com/?l=bugtraq&m=100706579514862&w=2 1185 5.6 Discovery of Issues in the Wild 1187 "sadmind" 1188 Nancy Lin 1189 SF-INCIDENTS mailing list 1190 December 9, 1999 1191 http://marc.theaimsgroup.com/?l=incidents&m=94476722417209&w=2 1193 "sadmind exploits (remote sparc/x86)" 1194 Marcy Abene 1195 Bugtraq mailing list 1196 December 10, 1999 1197 http://marc.theaimsgroup.com/?l=bugtraq&m=94486731225359&w=2 1199 "IIS %c1%1c remote command execution" 1200 Rain Forest Puppy 1201 Bugtraq mailing list 1202 October 17, 2000 1203 http://marc.theaimsgroup.com/?l=bugtraq&m=97180137413891&w=2 1205 5.7 Researcher Credibility and Vulnerability Reproduction 1207 "vCard DoS on Outlook 2000" 1208 Joel Moses 1209 Bugtraq mailing list 1210 August 31, 2000 1211 http://marc.theaimsgroup.com/?l=bugtraq&m=96774764029236&w=2 1213 "Microsoft Outlook 2000 vCard Buffer Overrun" 1214 @stake 1215 February 26, 2001 1216 http://www.atstake.com/research/advisories/2001/a022301-1.txt 1218 "Re: Microsoft Security Bulletin MS01-012" 1219 Joel Moses 1220 Bugtraq mailing list 1221 February 23, 2001 1222 http://marc.theaimsgroup.com/?l=bugtraq&m=98322714210100&w=2 1224 5.8 Miscellaneous 1226 "Vulnerability disclosure publications and discussion tracking" 1227 University of Oulu 1228 November 20, 2001 1229 http://www.ee.oulu.fi/research/ouspg/sage/disclosure-tracking/ 1231 "Devil in the details - why package signing matters" 1232 Kurt Seifried 1233 October 24, 2001 1234 http://www.seifried.org/security/articles/ 1235 20011023-devil-in-details.html 1237 6 Acknowledgements 1239 We gratefully acknowledge the constructive comments received from 1240 several contributors. Any errors or inconsistencies in this document 1241 are solely the responsibility of the authors, and not of the 1242 reviewers. This document does not necessarily reflect the opinion of 1243 the reviewers or their parent organizations. 1245 We would like to thank Andy Balinsky, Mary Ann Davidson, Elias Levy, 1246 Russ Cooper, Scott Blake, Seth Arnold, Rain Forest Puppy, Marcus 1247 Ranum, Lori Woeler, Adam Shostack, Mark Loveless, Scott Culp, and 1248 Shawn Hernan for their valuable input. 1250 7 Security Considerations 1252 This entire document discusses security issues. 1254 8 Authors' Addresses 1256 Steve Christey 1257 The MITRE Corporation 1258 202 Burlington Road 1259 Bedford, MA 01730 1260 USA 1262 E-Mail: coley@mitre.org 1264 Chris Wysopal 1265 @stake, Inc. 1266 196 Broadway 1267 Cambridge, MA 02139-1902 1268 USA 1270 E-Mail: cwysopal@atstake.com 1272 9 Full Copyright Statement 1274 Copyright (C) The Internet Society (2002). All Rights Reserved. 1276 This document and translations of it may be copied and furnished to 1277 others, and derivative works that comment on or otherwise explain it 1278 or assist in its implementation may be prepared, copied, published 1279 and distributed, in whole or in part, without restriction of any 1280 kind, provided that the above copyright notice and this paragraph are 1281 included on all such copies and derivative works. However, this 1282 document itself may not be modified in any way, such as by removing 1283 the copyright notice or references to the Internet Society or other 1284 Internet organisations, except as needed for the purpose of 1285 developing Internet standards in which case the procedures for 1286 copyrights defined in the Internet Standards process must be 1287 followed, or as required to translate it into languages other than 1288 English. 1290 The limited permissions granted above are perpetual and will not be 1291 revoked by the Internet Society or its successors or assigns. 1293 This document and the information contained herein is provided on an 1294 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1295 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1296 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1297 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1298 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1300 This document expires August 12, 2002.