├── README.md ├── CVE-ASSIGNMENT-RHT.md └── LICENSE /README.md: -------------------------------------------------------------------------------- 1 | # CVE-HOWTO 2 | CVE assignment documentation - this document replaces http://people.redhat.com/kseifrie/CVE-OpenSource-Request-HOWTO.html 3 | 4 | Please note that this document pertains to CVE's for issues found in Open Source programs, not closed source programs, if you need a CVE for a closed source program I suggest you go to MITRE directly. 5 | 6 | Copyright: Red Hat 2016 7 | Author: Kurt Seifried (kseifried@redhat.com) 8 | 9 | ## What is CVE? 10 | 11 | http://cve.mitre.org/about/faqs.html 12 | 13 | A CVE is a common name for a single security vulnerability so that we can identify and talk about issues sanely (e.g. "that OpenSSL vulnerability, from like 2009, the DoS one" vs. "CVE-2009-3555"). CVE allows multiple vendors, products, and customers to properly track security vulnerabilities and make sure they are dealt with. 14 | 15 | The CVE database is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration." 16 | 17 | ## Why should I get a CVE for my security issue? 18 | 19 | Because it makes it much easier to track, discuss and otherwise handle security issues for everyone. Upstream vendors, downstream vendors, security tracking firms, customers, security products, etc. all increasingly rely upon CVE to identify issues clearly. 20 | 21 | ## Why should I get my CVE before going public? 22 | 23 | Getting the CVE before public release makes tracking the issue much easier, if you release the issue and then get a CVE for it everyone will have to update their information (considering how many organizations consume security reports, this is a lot of effort). Also if other similar issues are released it makes tracking much easier rather than playing the "well it sounds like this one but maybe it's that other one?" 24 | 25 | ## How do I request a CVE? 26 | 27 | There are several main ways to get a CVE: 28 | 29 | 1. Does the software in question belong to an organization that can assign CVEs? If so you should contact them first to request a CVE. If they are not responsive you should contact their parents CVE organization for resolution. A list of CNAs for MITRE is available at https://cve.mitre.org/cve/cna.html and for Open Source CNAs a list is maintained at https://github.com/distributedweaknessfiling/DWF-CNA-Registry 30 | 2. If the software in question doesn’t belong to an organization that can assign CVEs there are entities that do CVE assignments for various software categories (e.g. the DWF can do CVE assignments for Open Source software), the DWF is available at https://iwantacve.org/ 31 | 3. There are also organizations that to security vulnerability coordination and can assign CVEs to vulnerabilities such as CERT/CC, Hackerone, JPCERT/CC and so on, for a list of these please see https://cve.mitre.org/cve/cna.html 32 | 4. If there is no entity to assign a CVE you should ask MITRE directly for one via the web form: https://cve.mitre.org/cve/request_id.html 33 | 34 | Additionally for CVE requests for OpenSource software that are for public issues you can also request them via the Publicly on the oss-security@lists.openwall.com list currently. 35 | 36 | ## How to write a CVE request: 37 | 38 | MITRE maintains a CVE request web form at https://cveform.mitre.org/ and the DWF maintains one at https://iwantacve.org/ which show what information is required and what information is additonally nice to have. 39 | 40 | ## Why doesn't my CVE show up in the database? 41 | 42 | The main CVE database is at: 43 | 44 | http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=my+program 45 | 46 | The National Vulnerability database also maintains a CVE data with additional information such as CVSS scoring information. 47 | 48 | https://web.nvd.nist.gov/view/vuln/search 49 | 50 | Both currently rely on Mitre for entries to be created and added. MITRE does not add CVE text until they have researched the issue and written it up. Currently (as of late 2016) MITRE is transitioning to allowing CVE Numbering Authorities (CNAs) to submit CVE description text. 51 | 52 | ## Why was the CVE assigned days/weeks/months before going public? 53 | 54 | Mitre has a "Date Entry Created" field in their database, this is the date the CVE was either assigned by Mitre to a specific issue, or the date that CVE was given by Mitre to another organization (such as Red Hat) for future use. For example CVE-2015-0201 through CVE-2015-0300 were assigned on November 14, 2014 to Red Hat, as of late January 2015 Red Hat has only used approximately half of these. For more information on this and the other fields please see http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures 55 | 56 | 57 | -------------------------------------------------------------------------------- /CVE-ASSIGNMENT-RHT.md: -------------------------------------------------------------------------------- 1 | CVE Assignment HOWTO 2 | 3 | Copyright: Red Hat 2015 Author: Kurt Seifried (kseifried@redhat.com) 4 | 5 | This document actually described the internal procedure used at Red Hat to assign CVEs. 6 | 7 | # Work flow 8 | 9 | This is the work flow used to assign a CVE(s) at Red Hat. This is for both internally reported issues and issues where people have asked us to assign a CVE. 10 | 11 | ## Determine if this issue is a security vulnerability 12 | 13 | Some security issues are not vulnerabilities. For example a buffer overflow vulnerability that requires administrative level access to exploit (e.g. argument processing in the configuration file for a daemon) does not typically result in a trust boundary being violated, ergo it is not a vulnerability (this is not to say it isn't a security issue that should be dealt with). 14 | 15 | ### Security vulnerability 16 | 17 | A security vulnerability is something that allows an attacker to cross a trust boundary, for example this could allow an attacker to gain privileges they do not have, to execute arbitrary code when they should not be able to, or to crash a daemon or a system that they should not be able to turn off for example. Trust boundaries can be subtle as well, for example if a program advertises a security feature like "default firewall is enabled and only allows port 22 for SSH" and then some flaw results in the firewall also allowing other protocols (even if unused) this would usually be classed as a security vulnerability. 18 | 19 | It is important to also note that the line for what is/is not a security vulnerability is constantly moving. For example DES encryption used to be secure, but then computers got very fast and DES can now be cracked in near real time on a laptop. Other changes include default passwords, these used to be fine, but are now seen as a problem. A great example is in late 2014, downloads of software updates over HTTP were (and indeed still are) common, however unless there is some additional protections (such as RPM signing), HTTP and other clear text protocols being used to provide software updates are now seen as a vulnerability, and sites should switch to HTTPS or similar. 20 | 21 | In summary a security vulnerability generally allows: 22 | 23 | 1. An attacker to access something 24 | 2. An attacker to execute arbitrary code/control program flow 25 | 3. Execute a denial of service easily 26 | 27 | ### Security issue 28 | 29 | Security issues are security related problems that do not result in a trust boundary being crossed. For example a buffer overflow may exist in argument processing for a daemon, but if the only way to pass these arguments is via a configuration file owned by root:root then, generally speaking, this would be seen as a hardening issue and not an actual vulnerability. 30 | 31 | ## CVE SPLIT/MERGE 32 | 33 | The official CVE SPLIT/MERGE guidelines are here: https://cve.mitre.org/cve/editorial_policies/cd_abstraction.html 34 | 35 | However I wanted to include a quick and dirty version. Basically CVE SPLIT/MERGE can be summarized as: 36 | 37 | 1. Take all your security vulnerabilities and determine the root cause 38 | 2. Split them by codebase if multiple programs are affected (this can be subtle, e.g. MySQL/MariaDB or Tomcat and JBoss) 39 | 3. Split them by vulnerability type (e.g. buffer overflow, XSS, CSRF, etc.) 40 | 4. Split them by versions affected if different (e.g. vulnerable in 1.1 through 1.5 and the other vulnerability affects 1.4 through 1.5) 41 | 42 | There are of course many exceptions to these rules, for example if it is a common piece of code that has been recycled or embedded (e.x. expat/libxml2/gzip) then typically a single CVE would be used. 43 | 44 | The simplest way to cover all the exceptions is "be pragmatic", does assigning multiple CVEs help cut down on potential confusion/problems, or is it merely being pedantic? A good example of this is CVE-2009-3555 (a vulnerability in TLS), rather than assign several hundred CVE's Mitre simple assigned a single CVE for this protocol vulnerability. 45 | 46 | ## Take CVE's from the CVE Pool 47 | 48 | Take CVEs from the internal Red Hat pool and make sure the changes commit correctly (e.g. that someone else hasn't used the CVE as well). 49 | 50 | ## Add CVE's to BZ as needed 51 | 52 | If we have Bugzilla entries for the issues please add the CVEs as appropriate. 53 | 54 | ## Announce CVEs as needed 55 | 56 | If these CVEs are for public issues (this is rare as public issues should have CVEs requested on oss-security) please post a mention of this CVE to oss-security so the community and Mitre are aware. 57 | 58 | # Embargoed CVEs 59 | 60 | If these CVEs are for embargoed issues please simply reply to the person requsting them, if they were requested via the distros@ list also include distros@ in the reply. 61 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | CC0 1.0 Universal 2 | 3 | Statement of Purpose 4 | 5 | The laws of most jurisdictions throughout the world automatically confer 6 | exclusive Copyright and Related Rights (defined below) upon the creator and 7 | subsequent owner(s) (each and all, an "owner") of an original work of 8 | authorship and/or a database (each, a "Work"). 9 | 10 | Certain owners wish to permanently relinquish those rights to a Work for the 11 | purpose of contributing to a commons of creative, cultural and scientific 12 | works ("Commons") that the public can reliably and without fear of later 13 | claims of infringement build upon, modify, incorporate in other works, reuse 14 | and redistribute as freely as possible in any form whatsoever and for any 15 | purposes, including without limitation commercial purposes. These owners may 16 | contribute to the Commons to promote the ideal of a free culture and the 17 | further production of creative, cultural and scientific works, or to gain 18 | reputation or greater distribution for their Work in part through the use and 19 | efforts of others. 20 | 21 | For these and/or other purposes and motivations, and without any expectation 22 | of additional consideration or compensation, the person associating CC0 with a 23 | Work (the "Affirmer"), to the extent that he or she is an owner of Copyright 24 | and Related Rights in the Work, voluntarily elects to apply CC0 to the Work 25 | and publicly distribute the Work under its terms, with knowledge of his or her 26 | Copyright and Related Rights in the Work and the meaning and intended legal 27 | effect of CC0 on those rights. 28 | 29 | 1. Copyright and Related Rights. A Work made available under CC0 may be 30 | protected by copyright and related or neighboring rights ("Copyright and 31 | Related Rights"). Copyright and Related Rights include, but are not limited 32 | to, the following: 33 | 34 | i. the right to reproduce, adapt, distribute, perform, display, communicate, 35 | and translate a Work; 36 | 37 | ii. moral rights retained by the original author(s) and/or performer(s); 38 | 39 | iii. publicity and privacy rights pertaining to a person's image or likeness 40 | depicted in a Work; 41 | 42 | iv. rights protecting against unfair competition in regards to a Work, 43 | subject to the limitations in paragraph 4(a), below; 44 | 45 | v. rights protecting the extraction, dissemination, use and reuse of data in 46 | a Work; 47 | 48 | vi. database rights (such as those arising under Directive 96/9/EC of the 49 | European Parliament and of the Council of 11 March 1996 on the legal 50 | protection of databases, and under any national implementation thereof, 51 | including any amended or successor version of such directive); and 52 | 53 | vii. other similar, equivalent or corresponding rights throughout the world 54 | based on applicable law or treaty, and any national implementations thereof. 55 | 56 | 2. Waiver. To the greatest extent permitted by, but not in contravention of, 57 | applicable law, Affirmer hereby overtly, fully, permanently, irrevocably and 58 | unconditionally waives, abandons, and surrenders all of Affirmer's Copyright 59 | and Related Rights and associated claims and causes of action, whether now 60 | known or unknown (including existing as well as future claims and causes of 61 | action), in the Work (i) in all territories worldwide, (ii) for the maximum 62 | duration provided by applicable law or treaty (including future time 63 | extensions), (iii) in any current or future medium and for any number of 64 | copies, and (iv) for any purpose whatsoever, including without limitation 65 | commercial, advertising or promotional purposes (the "Waiver"). Affirmer makes 66 | the Waiver for the benefit of each member of the public at large and to the 67 | detriment of Affirmer's heirs and successors, fully intending that such Waiver 68 | shall not be subject to revocation, rescission, cancellation, termination, or 69 | any other legal or equitable action to disrupt the quiet enjoyment of the Work 70 | by the public as contemplated by Affirmer's express Statement of Purpose. 71 | 72 | 3. Public License Fallback. Should any part of the Waiver for any reason be 73 | judged legally invalid or ineffective under applicable law, then the Waiver 74 | shall be preserved to the maximum extent permitted taking into account 75 | Affirmer's express Statement of Purpose. In addition, to the extent the Waiver 76 | is so judged Affirmer hereby grants to each affected person a royalty-free, 77 | non transferable, non sublicensable, non exclusive, irrevocable and 78 | unconditional license to exercise Affirmer's Copyright and Related Rights in 79 | the Work (i) in all territories worldwide, (ii) for the maximum duration 80 | provided by applicable law or treaty (including future time extensions), (iii) 81 | in any current or future medium and for any number of copies, and (iv) for any 82 | purpose whatsoever, including without limitation commercial, advertising or 83 | promotional purposes (the "License"). The License shall be deemed effective as 84 | of the date CC0 was applied by Affirmer to the Work. Should any part of the 85 | License for any reason be judged legally invalid or ineffective under 86 | applicable law, such partial invalidity or ineffectiveness shall not 87 | invalidate the remainder of the License, and in such case Affirmer hereby 88 | affirms that he or she will not (i) exercise any of his or her remaining 89 | Copyright and Related Rights in the Work or (ii) assert any associated claims 90 | and causes of action with respect to the Work, in either case contrary to 91 | Affirmer's express Statement of Purpose. 92 | 93 | 4. Limitations and Disclaimers. 94 | 95 | a. No trademark or patent rights held by Affirmer are waived, abandoned, 96 | surrendered, licensed or otherwise affected by this document. 97 | 98 | b. Affirmer offers the Work as-is and makes no representations or warranties 99 | of any kind concerning the Work, express, implied, statutory or otherwise, 100 | including without limitation warranties of title, merchantability, fitness 101 | for a particular purpose, non infringement, or the absence of latent or 102 | other defects, accuracy, or the present or absence of errors, whether or not 103 | discoverable, all to the greatest extent permissible under applicable law. 104 | 105 | c. Affirmer disclaims responsibility for clearing rights of other persons 106 | that may apply to the Work or any use thereof, including without limitation 107 | any person's Copyright and Related Rights in the Work. Further, Affirmer 108 | disclaims responsibility for obtaining any necessary consents, permissions 109 | or other rights required for any use of the Work. 110 | 111 | d. Affirmer understands and acknowledges that Creative Commons is not a 112 | party to this document and has no duty or obligation with respect to this 113 | CC0 or use of the Work. 114 | 115 | For more information, please see 116 | 117 | --------------------------------------------------------------------------------