# The Monero Project Vulnerability Response Process ## Preamble (Monero/Kovri) 1. This Vulnerability Response Process and subsequent bounty reward apply to the following: - Code implementation as seen in the Monero Project GitHub repositories - Written research from the Monero Research Lab which dictates said code implementation 2. Researchers/Hackers: while you research/hack, we ask that you please refrain from committing the following: - Denial of Service / Active exploiting against the Monero/Kovri networks - Social Engineering of Monero/Kovri Project staff or contractors - Any physical or electronic attempts against Monero/Kovri community property and/or data centers 3. As a pro-privacy project we have volunteers running copies of the websites on hidden services on Tor and I2P, as well as on multiple public domains. **The live sites are NOT in the scope of this process; only the code is!** 4. Bounty will be released for all projects in Monero XMR only. For more information on how to use Monero, visit the [Monero website](https://getmonero.org) 5. Bounty is not eligible to those who: - do not abide by the VRP for responsible disclosure - do not allow the completion of VRP points I through IV ## Preamble (Kovri) 1. While Kovri is in a pre-Alpha release state, do not use HackerOne for disclosure. All Kovri issues MUST be directed to either [GitHub](https://github.com/monero-project/kovri) or Email 2. Bounty will not be available for Kovri until **Kovri Beta** is released ## I. Points of contact for security issues ### Monero (CLI/GUI/website) ``` ric [at] getmonero.org PGP fingerprint = BDA6 BD70 42B7 21C4 67A9 759D 7455 C5E3 C0CD CEB9 luigi1111 [at] getmonero.org PGP fingerprint = 8777 AB8F 778E E894 87A2 F8E7 F4AC A018 3641 E010 ``` ### Monero (CLI/GUI) ``` moneromooo on Freenode PGP fingerprint = 48B0 8161 FBDA DFE3 93AD FC3E 686F 0745 4D6C EFC3 If pasting GPG encrypted data, use fpaste.org or pastebin.mozilla.org or paste.debian.net as these don't blackball Tor via Cloudflare. OTR: 6C7966BB 72E42F33 E1A3F137 2133AC39 D343514A ``` ### Kovri (CLI/Website) ``` anonimal [at] getmonero.org PGP fingerprint = 1218 6272 CD48 E253 9E2D D29B 66A7 6ECF 9144 09F1 ``` ## II. Security response team - fluffypony - luigi1111 - moneromooo - anonimal ## III. Incident response 1. Researcher submits report via one or both of two methods: - a. PGP encrypted Email (use the appropriate fingerprints [listed in section I](#i-points-of-contact-for-security-issues) or as included in the Monero repo in `utils/gpg_keys/`) - b. [HackerOne](https://hackerone.com/monero) 2. Response Team designates a Response Manager who is in charge of the particular report based on availability and/or knowledge-set 3. In no more than 3 working days, Response Team should gratefully respond to researcher using only encrypted, secure channels 4. Response Manager makes inquiries to satisfy any needed information to confirm if submission is indeed a vulnerability - a. If submission proves to be vulnerable with PoC code / exploit, proceed to next step - b. If not vulnerable: - i. Response Manager responds with reasons why submission is not a vulnerability - ii. Response Manager moves discussion to a new or existing ticket on GitHub if necessary 5. If over email, Response Manager opens a HackerOne issue for new submission 6. Establish severity of vulnerability: - a. HIGH: impacts network as a whole, has potential to break entire monero/kovri network, results in the loss of monero, or is on a scale of great catastrophe - b. MEDIUM: impacts individual nodes, routers, wallets, or must be carefully exploited - c. LOW: is not easily exploitable or is low impact - d. If there are any disputes regarding bug severity, the Monero Response team will ultimately define bug severity 7. Respond according to the severity of the vulnerability: - a. HIGH severities must be notified on website and reddit /r/Monero (/r/Kovri for kovri) within 3 working days of classification - i. The notification should list appropriate steps for users to take, if any - ii. The notification must not include any details that could suggest an exploitation path - iii. The latter takes precedence over the former - b. MEDIUM and HIGH severities will require a Point Release - c. LOW severities will be addressed in the next Regular Release 8. Response Team applies appropriate patch(es) - a. Response Manager designates a PRIVATE git "hotfix branch" to work in - b. Patches are reviewed with the researcher - c. Any messages associated with PUBLIC commits during the time of review should not make reference to the security nature of the PRIVATE branch or its commits - d. Vulnerability announcement is drafted - i. Include the severity of the vulnerability - ii. Include all vulnerable systems/apps/code - iii. Include solutions (if any) if patch cannot be applied - e. Release date is discussed 9. At release date, Response Team coordinates with developers to finalize update: - a. Response Manager propagates the "hotfix branch" to trunk - b. Response Manager includes vulnerability announcement draft in release notes - c. Proceed with the Point or Regular Release ## IV. Post-release disclosure process 1. Response Team has 90 days to fulfill all points within section III 2. If the Incident Response process in section III is successfully completed: - a. Researcher decides whether or not to opt out of receiving name/handle/organization credit. By default, the researcher will receive name/handle/organization credit. - i. If bounty is applicable, release bounty to the researcher as defined in section "Bounty Distribution" - b. Finalize vulnerability announcement draft and include the following: - i. Project name and URL - ii. Versions known to be affected - iii. Versions known to be not affected (for example, the vulnerable code was introduced in a recent version, and older versions are therefore unaffected) - iv. Versions not checked - v. Type of vulnerability and its impact - vi. If already obtained or applicable, a CVE-ID - vii. The planned, coordinated release date - viii. Mitigating factors (for example, the vulnerability is only exposed in uncommon, non-default configurations) - ix. Workarounds (configuration changes users can make to reduce their exposure to the vulnerability) - x. If applicable, credits to the original reporter - c. Release finalized vulnerability announcement on website and reddit /r/Monero (/r/Kovri for kovri) - d. For HIGH severities, release finalized vulnerability announcement on well-known mailing lists: - i. oss-security@lists.openwall.com - ii. bugtraq@securityfocus.com - e. If applicable, developers request a CVE-ID - i. The commit that applied the fix is made reference too in a future commit and includes a CVE-ID 3. If the Incident Response process in section III is *not* successfully completed: - a. Response Team and developers organize an IRC meeting to discuss why/what points in section III were not resolved and how the team can resolve them in the future - b. Any developer meetings immediately following the incident should include points made in section V - c. If disputes arise about whether or when to disclose information about a vulnerability, the Response Team will publicly discuss the issue via IRC and attempt to reach consensus - d. If consensus on a timely disclosure is not met (no later than 90 days), the researcher (after 90 days) has every right to expose the vulnerability to the public ## V. Bounty distribution - XMR for vulnerability-related bounties are solely contributed by community donators and escrowed by unpaid volunteers. Total availability of XMR contributed for bounties can be tracked [here](https://forum.getmonero.org/8/funding-required/87597/monero-bounty-for-hackerone). XMR market values can be found at the various exchanges. See also [Cryptowatch](https://cryptowat.ch/) and [Live Coin Watch](https://www.livecoinwatch.com/). - As reports come in and payouts are made, the total bounty supply shrinks. This gives incentive for bug hunters to report bugs a.s.a.p. - The following percentages apply to available XMR bounty (severity is defined above in section III. 6.): 1. 10% reserved for LOW severity bugs 2. 30% reserved for MEDIUM severity bugs 3. 60% for HIGH severity bugs - Each bug will at most receive 10% of each category. Example: 10% of 60% for a HIGH severity bug. ## VI. Incident analysis 1. Isolate codebase - a. Response Team and developers should coordinate to work on the following: - i. Problematic implementation of classes/libraries/functions, etc. - ii. Focus on apps/distro packaging, etc. - iii. Operator/config error, etc. 2. Auditing - a. Response Team and developers should coordinate to work on the following: - i. Auditing of problem area(s) as discussed in point 1 - ii. Generate internal reports and store for future reference - iii. If results are not sensitive, share with the public via IRC or GitHub 3. Response Team has 45 days following completion of section III to ensure completion of section V ## VII. Resolutions Any further questions or resolutions regarding the incident(s) between the researcher and response + development team after public disclosure can be addressed via the following: - IRC on Freenode - `#monero-dev` - `#kovri-dev` - [GitHub](https://github.com/monero-project/monero/issues/) - [Monero (CLI)](https://github.com/monero-project/monero/issues/) - [Monero (GUI)](https://github.com/monero-project/monero-core/issues/) - [Monero (Website)](https://github.com/monero-project/monero-site/issues/) - [Kovri](https://github.com/monero-project/kovri/issues/) - [Kovri (Website)](https://github.com/monero-project/kovri-site/issues/) - [HackerOne](https://hackerone.com/monero) - [Reddit /r/Monero](https://reddit.com/r/Monero/) - [Reddit /r/Kovri](https://reddit.com/r/Kovri/) - Email ## VIII. Continuous improvement 1. Response Team and developers should hold annual meetings to review the previous year's incidents 2. Response Team or designated person(s) should give a brief presentation, including: - a. Areas of Monero/Kovri affected by the incidents - b. Any network downtime or monetary cost (if any) of the incidents - c. Ways in which the incidents could have been avoided (if any) - d. How effective this process was in dealing with the incidents 3. After the presentation, Response Team and developers should discuss: - a. Potential changes to development processes to reduce future incidents - b. Potential changes to this process to improve future responses