|
1 | | -# Security |
2 | | - |
3 | | -> **IMPORTANT**: If you find a security issue, you can |
4 | | -report it to our [bug bounty program](https://hackerone.com/cosmos) on HackerOne. *DO NOT* open a public issue on the repository. |
5 | | - |
6 | | -## Bug Bounty |
7 | | - |
8 | | -As part of our [Coordinated Vulnerability Disclosure Policy](https://tendermint.com/security), we operate a |
9 | | -[bug bounty program](https://hackerone.com/cosmos) with Hacker One. |
10 | | - |
11 | | -See the policy linked above for more details on submissions and rewards and read |
12 | | -this [blog post](https://blog.cosmos.network/bug-bounty-program-for-tendermint-cosmos-833c67693586) for the program scope. |
13 | | - |
14 | | -The following is a list of examples of the kinds of bugs we're most interested |
15 | | -in for the Cosmos SDK. See [here](https://github.com/cometbft/cometbft/blob/master/SECURITY.md) for vulnerabilities we are interested |
16 | | -in for CometBFT and other lower-level libraries (eg. [IAVL](https://github.com/cosmos/iavl)). |
17 | | - |
18 | | -### Core packages |
19 | | - |
20 | | -* [`/baseapp`](https://github.com/cosmos/cosmos-sdk/tree/main/baseapp) |
21 | | -* [`/crypto`](https://github.com/cosmos/cosmos-sdk/tree/main/crypto) |
22 | | -* [`/types`](https://github.com/cosmos/cosmos-sdk/tree/main/types) |
23 | | -* [`/store`](https://github.com/cosmos/cosmos-sdk/tree/main/store) |
24 | | - |
25 | | -### Modules |
26 | | - |
27 | | -* [`x/auth`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth) |
28 | | -* [`x/bank`](https://github.com/cosmos/cosmos-sdk/tree/main/x/bank) |
29 | | -* [`x/staking`](https://github.com/cosmos/cosmos-sdk/tree/main/x/staking) |
30 | | -* [`x/slashing`](https://github.com/cosmos/cosmos-sdk/tree/main/x/slashing) |
31 | | -* [`x/evidence`](https://github.com/cosmos/cosmos-sdk/tree/main/x/evidence) |
32 | | -* [`x/distribution`](https://github.com/cosmos/cosmos-sdk/tree/main/x/distribution) |
33 | | -* [`x/mint`](https://github.com/cosmos/cosmos-sdk/tree/main/x/mint) |
34 | | - |
35 | | -We are interested in bugs in other modules, however the above are most likely to |
36 | | -have significant vulnerabilities, due to the complexity / nuance involved. We |
37 | | -also recommend you to read the [specification](https://github.com/cosmos/cosmos-sdk/blob/main/docs/building-modules/README.md) of each module before digging into |
38 | | -the code. |
39 | | - |
40 | | -### How we process Tx parameters |
41 | | - |
42 | | -* Integer operations on tx parameters, especially `sdk.Int` / `sdk.Dec` |
43 | | -* Gas calculation & parameter choices |
44 | | -* Tx signature verification (see [`x/auth/ante`](https://github.com/cosmos/cosmos-sdk/tree/main/x/auth/ante)) |
45 | | -* Possible Node DoS vectors (perhaps due to gas weighting / non constant timing) |
46 | | - |
47 | | -### Handling private keys |
48 | | - |
49 | | -* HD key derivation, local and Ledger, and all key-management functionality |
50 | | -* Side-channel attack vectors with our implementations |
51 | | - * e.g. key exfiltration based on time or memory-access patterns when decrypting privkey |
52 | | - |
53 | | -## Disclosure Process |
54 | | - |
55 | | -The Cosmos SDK team uses the following disclosure process: |
56 | | - |
57 | | -1. After a security report is received, the Cosmos SDK team works to verify the issue and confirm its severity level using Common Vulnerability Scoring System (CVSS). |
58 | | -1. The Cosmos SDK team collaborates with the CometBFT and Gaia teams to determine the vulnerability’s potential impact on the Cosmos Hub and partners. |
59 | | -1. Patches are prepared in private repositories for eligible releases of Cosmos SDK. See [Stable Release Policy](https://github.com/cosmos/cosmos-sdk/blob/main/RELEASE_PROCESS.md#stable-release-policy) for a list of eligible releases. |
60 | | -1. If it is determined that a CVE-ID is required, we request a CVE through a CVE Numbering Authority. |
61 | | -1. 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. |
62 | | -1. 24 hours after the notification, fixes are applied publicly and new releases are issued. |
63 | | -1. The Gaia team updates their CometBFT and Cosmos SDK dependencies to use these releases and then issues new Gaia releases. |
64 | | -1. After releases are available for CometBFT, Cosmos SDK, and Gaia, we notify the community again through the same channels. We also publish a Security Advisory on Github and publish the CVE, as long as the Security Advisory and the CVE do not include information on how to exploit these vulnerabilities beyond the information that is available in the patch. |
65 | | -1. After the community is notified, CometBFT pays out any relevant bug bounties to submitters. |
66 | | -1. One week after the releases go out, we publish a post with details and our response to the vulnerability. |
67 | | - |
68 | | -This process can take some time. Every effort is made to handle the bug in as timely a manner as possible. However, it's important that we follow this security process to ensure that disclosures are handled consistently and to keep Cosmos SDK and its downstream dependent projects--including but not limited to Gaia and the Cosmos Hub--as secure as possible. |
69 | | - |
70 | | -### Disclosure Communications |
71 | | - |
72 | | -Communications to partners usually include the following details: |
73 | | - |
74 | | -1. Affected version or versions |
75 | | -1. New release version |
76 | | -1. Impact on user funds |
77 | | -1. For timed releases, a date and time that the new release will be made available |
78 | | -1. Impact on the partners if upgrades are not completed in a timely manner |
79 | | -1. Potential required actions if an adverse condition arises during the security release process |
80 | | - |
81 | | -An example notice looks like: |
82 | | - |
83 | | -```text |
84 | | -Dear Cosmos SDK partners, |
85 | | -
|
86 | | -A critical security vulnerability has been identified in Cosmos SDK vX.X.X. |
87 | | -User funds are NOT at risk; however, the vulnerability can result in a chain halt. |
88 | | -
|
89 | | -This notice is to inform you that on [[**March 1 at 1pm EST/6pm UTC**]], we will be releasing Cosmos SDK vX.X.Y to fix the security issue. |
90 | | -We ask all validators to upgrade their nodes ASAP. |
91 | | -
|
92 | | -If the chain halts, validators with sufficient voting power must upgrade and come online for the chain to resume. |
93 | | -``` |
94 | | - |
95 | | -### Example Timeline |
96 | | - |
97 | | -The following timeline is an example of triage and response. Each task identifies the required roles and team members; however, multiple people can play each role and each person may play multiple roles. |
98 | | - |
99 | | -#### 24+ Hours Before Release Time |
100 | | - |
101 | | -1. Request CVE number (ADMIN) |
102 | | -1. Gather emails and other contact info for validators (COMMS LEAD) |
103 | | -1. Test fixes on a testnet (COSMOS SDK ENG) |
104 | | -1. Write “Security Advisory” for forum (COSMOS SDK LEAD) |
105 | | - |
106 | | -#### 24 Hours Before Release Time |
107 | | - |
108 | | -1. Post “Security Advisory” pre-notification on forum (COSMOS SDK LEAD) |
109 | | -1. Post Tweet linking to forum post (COMMS LEAD) |
110 | | -1. Announce security advisory/link to post in various other social channels (Telegram, Discord) (COMMS LEAD) |
111 | | -1. Send emails to partners or other users (PARTNERSHIPS LEAD) |
112 | | - |
113 | | -#### Release Time |
114 | | - |
115 | | -1. Cut Cosmos SDK releases for eligible versions (COSMOS SDK ENG) |
116 | | -1. Cut Gaia release for eligible versions (GAIA ENG) |
117 | | -1. Post “Security releases” on forum (COSMOS SDK LEAD) |
118 | | -1. Post new Tweet linking to forum post (COMMS LEAD) |
119 | | -1. Remind everyone using social channels (Telegram, Discord) that the release is out (COMMS LEAD) |
120 | | -1. Send emails to validators and other users (COMMS LEAD) |
121 | | -1. Publish Security Advisory and CVE if the CVE has no sensitive information (ADMIN) |
122 | | - |
123 | | -#### After Release Time |
124 | | - |
125 | | -1. Write forum post with exploit details (COSMOS SDK LEAD) |
126 | | -1. Approve payout on HackerOne for submitter (ADMIN) |
127 | | - |
128 | | -#### 7 Days After Release Time |
129 | | - |
130 | | -1. Publish CVE if it has not yet been published (ADMIN) |
131 | | -1. Publish forum post with exploit details (COSMOS SDK ENG, COSMOS SDK LEAD) |
| 1 | +# Coordinated Vulnerability Disclosure Policy |
| 2 | + |
| 3 | +The Cosmos ecosystem believes that strong security is a blend of highly |
| 4 | +technical security researchers who care about security and the forward |
| 5 | +progression of the ecosystem and the attentiveness and openness of Cosmos core |
| 6 | +contributors to help continually secure our operations. |
| 7 | + |
| 8 | +> **IMPORTANT**: *DO NOT* open public issues on this repository for security |
| 9 | +> vulnerabilities. |
| 10 | +
|
| 11 | +## Scope |
| 12 | + |
| 13 | +| Scope | |
| 14 | +|-----------------------| |
| 15 | +| last release (tagged) | |
| 16 | +| main branch | |
| 17 | + |
| 18 | +The latest **release tag** of this repository is supported for security updates |
| 19 | +as well as the **main** branch. Security vulnerabilities should be reported if |
| 20 | +the vulnerability can be reproduced on either one of those. |
| 21 | + |
| 22 | +## Reporting a Vulnerability |
| 23 | + |
| 24 | +| Reporting methods | |
| 25 | +|---------------------------------------------------------------| |
| 26 | +| [GitHub Private Vulnerability Reporting][gh-private-advisory] | |
| 27 | +| [HackerOne bug bounty program][h1] | |
| 28 | + |
| 29 | +All security vulnerabilities can be reported under GitHub's [Private |
| 30 | +vulnerability reporting][gh-private-advisory] system. This will open a private |
| 31 | +issue for the developers. Try to fill in as much of the questions as possible. |
| 32 | +If you are not familiar with the CVSS system for assessing vulnerabilities, just |
| 33 | +use the Low/High/Critical severity ratings. A partially filled in report for a |
| 34 | +critical vulnerability is still better than no report at all. |
| 35 | + |
| 36 | +Vulnerabilities associated with the **Go, Rust or Protobuf code** of the |
| 37 | +repository may be eligible for a [bug bounty][h1]. Please see the bug bounty |
| 38 | +page for more details on submissions and rewards. If you think the vulnerability |
| 39 | +is eligible for a payout, **report on HackerOne first**. |
| 40 | + |
| 41 | +Vulnerabilities in services and their source codes (JavaScript, web page, Google |
| 42 | +Workspace) are not in scope for the bug bounty program, but they are welcome to |
| 43 | +be reported in GitHub. |
| 44 | + |
| 45 | +### Guidelines |
| 46 | + |
| 47 | +We require that all researchers: |
| 48 | + |
| 49 | +* Abide by this policy to disclose vulnerabilities, and avoid posting |
| 50 | + vulnerability information in public places, including GitHub, Discord, |
| 51 | + Telegram, and Twitter. |
| 52 | +* Make every effort to avoid privacy violations, degradation of user experience, |
| 53 | + disruption to production systems (including but not limited to the Cosmos |
| 54 | + Hub), and destruction of data. |
| 55 | +* Keep any information about vulnerabilities that you’ve discovered confidential |
| 56 | + between yourself and the Cosmos engineering team until the issue has been |
| 57 | + resolved and disclosed. |
| 58 | +* Avoid posting personally identifiable information, privately or publicly. |
| 59 | + |
| 60 | +If you follow these guidelines when reporting an issue to us, we commit to: |
| 61 | + |
| 62 | +* Not pursue or support any legal action related to your research on this |
| 63 | + vulnerability |
| 64 | +* Work with you to understand, resolve and ultimately disclose the issue in a |
| 65 | + timely fashion |
| 66 | + |
| 67 | +### More information |
| 68 | + |
| 69 | +* See [TIMELINE.md] for an example timeline of a disclosure. |
| 70 | +* See [DISCLOSURE.md] to see more into the inner workings of the disclosure |
| 71 | + process. |
| 72 | +* See [EXAMPLES.md] for some of the examples that we are interested in for the |
| 73 | + bug bounty program. |
| 74 | + |
| 75 | +[gh-private-advisory]: /../../security/advisories/new |
| 76 | +[h1]: https://hackerone.com/cosmos |
| 77 | +[TIMELINE.md]: https://github.com/cosmos/security/blob/main/TIMELINE.md |
| 78 | +[DISCLOSURE.md]: https://github.com/cosmos/security/blob/main/DISCLOSURE.md |
| 79 | +[EXAMPLES.md]: https://github.com/cosmos/security/blob/main/EXAMPLES.md |
0 commit comments