meta/VULNERABILITY_RESPONSE_PROCESS.md

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

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 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 or as included in the Monero repo in utils/gpg_keys/)
   • b. HackerOne

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. XMR market values can be found at the various exchanges. See also Cryptowatch and Live Coin Watch.
• 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
  • Monero (CLI)
  • Monero (GUI)
  • Monero (Website)
  • Kovri
  • Kovri (Website)
• HackerOne
• Reddit /r/Monero
• Reddit /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