-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(docs): update SECURITY.md (#1019)
* chore(docs): update SECURITY.md * Update SECURITY.md Co-authored-by: Daniel Burckhardt <[email protected]> * Update SECURITY.md Co-authored-by: Tomas Guerra <[email protected]> Co-authored-by: Daniel Burckhardt <[email protected]> Co-authored-by: Tomas Guerra <[email protected]>
- Loading branch information
3 people
committed
Oct 29, 2022
1 parent
41d002a
commit 01046c0
Showing
1 changed file
with
39 additions
and
92 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,115 +1,62 @@ | ||
| # Security | ||
|
|
||
| As part of our vulnerability disclosure policy, we operate a bug | ||
| bounty. | ||
|
|
||
| See the policy for more details on submissions and rewards, and see "Example Vulnerabilities" (below) for examples of the kinds of bugs the team is most interested in. | ||
| As part of our vulnerability disclosure policy, we operate a security vulnerability program through [Immunefi](https://immunefi.com/). This document serves as a complementary guideline for reporting vulnerabilities and how the disclosure process is managed. Please refer to the official Evmos [bug bounty program](https://immunefi.com/bounty/evmos/) for up-to-date information. | ||
|
|
||
| ## Guidelines | ||
|
|
||
| We require that all researchers: | ||
|
|
||
| * Use the bug bounty to disclose all vulnerabilities, and avoid posting vulnerability information in public places, including Github Issues, Discord channels, and Telegram groups | ||
| * Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems (including but not limited to the Evmos mainnet and/or testnets), and destruction of data | ||
| * Keep any information about vulnerabilities that you’ve discovered confidential between yourself and the engineering team until the issue has been resolved and disclosed | ||
| * Avoid posting personally identifiable information, privately or publicly | ||
| - Use the Evmos [bug bounty program](https://immunefi.com/bounty/evmos/) on Immunefi to disclose all vulnerabilities, and avoid posting vulnerability information in public places, including GitHub, Discord, Telegram, Twitter or other non-private channels. | ||
| - Make every effort to avoid privacy violations, degradation of user experience, disruption to production systems, and destruction of data. | ||
| - Keep any information about vulnerabilities that you’ve discovered confidential between yourself and the engineering team until the issue has been resolved and disclosed | ||
| - Avoid posting personally identifiable information, privately or publicly | ||
|
|
||
| If you follow these guidelines when reporting an issue to us, we commit to: | ||
|
|
||
| * Not pursue or support any legal action related to your research on this vulnerability | ||
| * Work with you to understand, resolve and ultimately disclose the issue in a timely fashion | ||
| - Not pursue or support any legal action related to your research on this vulnerability | ||
| - Work with you to understand, resolve and ultimately disclose the issue in a timely fashion | ||
|
|
||
| ## Disclosure Process | ||
|
|
||
| Tharsis uses the following disclosure process: | ||
|
|
||
| 1. Once a security report is received, the team works to verify the issue and confirm its severity level using [CVSS](https://nvd.nist.gov/vuln-metrics/cvss). | ||
| 2. The team determines the vulnerability’s potential impact on Evmos. | ||
| 3. Patches are prepared for eligible releases of Evmos in private repositories. See “Supported Releases” below for more information on which releases are considered eligible. | ||
| 4. We notify the community that a security release is coming, to give users time to prepare their systems for the update. Notifications can include forum posts, tweets, and emails to partners and validators. | ||
| 5. 24 hours following this notification, the fixes are applied publicly and new releases are issued. | ||
| 6. The team updates their Evmos and Ethermint dependencies to use these releases, and then themselves issue new releases. | ||
| 7. Once releases are available for Evmos and Ethermint we notify the community, again, through the same channels as above. We also publish a Security Advisory on Github and publish a CVE (if applicable), as long as neither the Security Advisory nor the CVE include any information on how to exploit these vulnerabilities beyond what information is already available in the patch itself. | ||
| 8. Once the community is notified, we will pay out any relevant bug bounties to submitters. | ||
| 9. One week after the releases go out, we will publish a post with further details on the vulnerability as well as our response to it. | ||
|
|
||
| This process can take some time. Every effort will be made to handle the bug in as timely a manner as possible, however it's important that we follow the process described above to ensure that disclosures are handled consistently and to keep Ethermint and its downstream dependent projects--including but not limited to Evmos--as secure as possible. | ||
|
|
||
| ## Supported Releases | ||
|
|
||
| The team commits to releasing security patch releases for both the latest minor release as well for the major/minor release that Evmos is running. | ||
|
|
||
| If you are running older versions of Evmos, we encourage you to upgrade at your earliest opportunity so that you can receive security patches directly from the repo. While you are welcome to backport security patches to older versions for your own use, we will not publish or promote these backports. | ||
|
|
||
| ## Scope | ||
|
|
||
| Please note that, in the interest of the safety of our users and staff, a few things are explicitly excluded from scope: | ||
|
|
||
| * Any third-party services | ||
| * Findings from physical testing, such as office access | ||
| * Findings derived from social engineering (e.g., phishing) | ||
|
|
||
| ## Example Vulnerabilities | ||
|
|
||
| The following is a list of examples of the kinds of vulnerabilities that we’re most interested in. It is not exhaustive: there are other kinds of issues we may also be interested in! | ||
| Evmos uses the following disclosure process: | ||
|
|
||
| ### Specification | ||
| 1. Once a security report is received via the Immunefi Bug Bounty program, the team works to verify the issue and confirm its severity level using [CVSS](https://nvd.nist.gov/vuln-metrics/cvss) or [Immunefi’s Vulnerability Severity Classification System v2.2](https://immunefi.com/immunefi-vulnerability-severity-classification-system-v2-2/). | ||
| 1. Two people from the affected project will review, replicate and acknowledge the report within 48-96 hours of the alert according to the table below: | ||
| | Security Level | Hours to First Response (ACK) from Escalation | | ||
| | -------------------- | --------------------------------------------- | | ||
| | Critical | 48 | | ||
| | High | 96 | | ||
| | Medium | 96 | | ||
| | Low or Informational | 96 | | ||
| | None | 96 | | ||
|
|
||
| * Conceptual flaws | ||
| * Ambiguities, inconsistencies, or incorrect statements | ||
| * Mis-match between specification and implementation of any component | ||
|
|
||
| ### Consensus | ||
|
|
||
| Assuming less than 1/3 of the voting power is Byzantine (malicious): | ||
|
|
||
| * Validation of blockchain data structures, including blocks, block parts, votes, and so on | ||
| * Execution of blocks | ||
| * Validator set changes | ||
| * Proposer round robin | ||
| * Two nodes committing conflicting blocks for the same height (safety failure) | ||
| * A correct node signing conflicting votes | ||
| * A node halting (liveness failure) | ||
| * Syncing new and old nodes | ||
|
|
||
| Assuming more than 1/3 the voting power is Byzantine: | ||
|
|
||
| * Attacks that go unpunished (unhandled evidence) | ||
|
|
||
| ### Networking | ||
|
|
||
| * Authenticated encryption (MITM, information leakage) | ||
| * Eclipse attacks | ||
| * Sybil attacks | ||
| * Long-range attacks | ||
| * Denial-of-Service | ||
|
|
||
| ### RPC | ||
|
|
||
| * Write-access to anything besides sending transactions | ||
| * Denial-of-Service | ||
| * Leakage of secrets | ||
|
|
||
| ### Denial-of-Service | ||
| 2. If the report is not applicable or reproducible, the Security Lead (or Security Secondary) will revert to the reporter to request more info or close the report. | ||
| 3. The report is confirmed by the Security Lead to the reporter. | ||
| 2. The team determines the vulnerability’s potential impact on Evmos. | ||
| 1. Vulnerabilities with `Informational` and `Low` categorization will result in creating a public issue. | ||
| 2. Vulnerabilities with `Medium` categorization will result in the creation of an internal ticket and patch of the code. | ||
| 3. Vulnerabilities with `High` or `Critical` will result in the [creation of a new Security Advisory](https://docs.github.com/en/code-security/repository-security-advisories/creating-a-repository-security-advisory) | ||
|
|
||
| Attacks may come through the P2P network or the RPC layer: | ||
| Once the vulnerability severity is defined, the following steps apply: | ||
|
|
||
| * Amplification attacks | ||
| * Resource abuse | ||
| * Deadlocks and race conditions | ||
| - For `High` and `Critical`: | ||
| 1. Patches are prepared for supported releases of Evmos in a [temporary private fork](https://docs.github.com/en/code-security/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability) of the repository. | ||
| 2. Only relevant parties will be notified about an upcoming upgrade. These being validators, the core developer team, and users directly affected by the vulnerability. | ||
| 3. 24 hours following this notification, relevant releases with the patch will be made public. | ||
| 4. The nodes and validators update their Evmos and Ethermint dependencies to use these releases. | ||
| 5. A week (or less) after the security vulnerability has been patched on Evmos, we will disclose that the mentioned release contained a security fix. | ||
| 6. After an additional 2 weeks, we will publish a public announcement of the vulnerability. We also publish a security Advisory on GitHub and publish a [CVE](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures) | ||
|
|
||
| ### Libraries | ||
| - For `Informational` , `Low` and `Medium` severities: | ||
| 1. `Medium` and `Low` severity bug reports are included in a public issue and will be incorporated in the current sprint and patched in the next release. `Informational` reports are additionally categorized as with low or medium priority and might not be included in the next release. | ||
| 2. One week after the releases go out, we will publish a post with further details on the vulnerability as well as our response to it. | ||
|
|
||
| * Serialization | ||
| * Reading/Writing files and databases | ||
| This process can take some time. Every effort will be made to handle the bug in as timely a manner as possible, however, it's important that we follow the process described above to ensure that disclosures are handled consistently and to keep Ethermint and its downstream dependent projects, including but not limited to Evmos, as secure as possible. | ||
|
|
||
| ### Cryptography | ||
| ### Payment Process | ||
|
|
||
| * Elliptic curves for validator signatures | ||
| * Hash algorithms and Merkle trees for block validation | ||
| * Authenticated encryption for P2P connections | ||
| The payment process will be executed according to Evmos’s Immunefi Bug Bounty program Rules. | ||
|
|
||
| ### Light Client | ||
| ### Contact | ||
|
|
||
| * Core verification | ||
| * Bisection/sequential algorithms | ||
| The Evmos Security Team is constantly being monitored. If you need to reach out to the team directly, please reach out via email: [[email protected]](mailto:[email protected]) |