github.com/MagHErmit/tendermint@v0.282.1/SECURITY.md (about) 1 # Security 2 3 ## Reporting a Bug 4 5 As part of our [Coordinated Vulnerability Disclosure Policy](https://tendermint.com/security), 6 we operate a [bug bounty][hackerone]. See the policy for more 7 details on submissions and rewards, and see "Example Vulnerabilities" (below) 8 for examples of the kinds of bugs we're most interested in. 9 10 ### Guidelines 11 12 We require that all researchers: 13 14 * Use the bug bounty to disclose all vulnerabilities, and avoid posting 15 vulnerability information in public places, including Github Issues, Discord 16 channels, and Telegram groups 17 * Make every effort to avoid privacy violations, degradation of user experience, 18 disruption to production systems (including but not limited to the Cosmos 19 Hub), and destruction of data 20 * Keep any information about vulnerabilities that you’ve discovered confidential 21 between yourself and the Tendermint Core engineering team until the issue has 22 been resolved and disclosed 23 * Avoid posting personally identifiable information, privately or publicly 24 25 If you follow these guidelines when reporting an issue to us, we commit to: 26 27 * Not pursue or support any legal action related to your research on this 28 vulnerability 29 * Work with you to understand, resolve and ultimately disclose the issue in a 30 timely fashion 31 32 ## Disclosure Process 33 34 Tendermint Core uses the following disclosure process: 35 36 1. Once a security report is received, the Tendermint Core team works to verify 37 the issue and confirm its severity level using CVSS. 38 2. The Tendermint Core team collaborates with the Gaia team to determine the 39 vulnerability’s potential impact on the Cosmos Hub. 40 3. Patches are prepared for eligible releases of Tendermint in private 41 repositories. See “Supported Releases” below for more information on which 42 releases are considered eligible. 43 4. If it is determined that a CVE-ID is required, we request a CVE through a CVE 44 Numbering Authority. 45 5. We notify the community that a security release is coming, to give users time 46 to prepare their systems for the update. Notifications can include forum 47 posts, tweets, and emails to partners and validators, including emails sent 48 to the [Tendermint Security Mailing List][tmsec-mailing]. 49 6. 24 hours following this notification, the fixes are applied publicly and new 50 releases are issued. 51 7. Cosmos SDK and Gaia update their Tendermint Core dependencies to use these 52 releases, and then themselves issue new releases. 53 8. Once releases are available for Tendermint Core, Cosmos SDK and Gaia, we 54 notify the community, again, through the same channels as above. We also 55 publish a Security Advisory on Github and publish the CVE, as long as neither 56 the Security Advisory nor the CVE include any information on how to exploit 57 these vulnerabilities beyond what information is already available in the 58 patch itself. 59 9. Once the community is notified, we will pay out any relevant bug bounties to 60 submitters. 61 10. One week after the releases go out, we will publish a post with further 62 details on the vulnerability as well as our response to it. 63 64 This process can take some time. Every effort will be made to handle the bug in 65 as timely a manner as possible, however it's important that we follow the 66 process described above to ensure that disclosures are handled consistently and 67 to keep Tendermint Core and its downstream dependent projects--including but not 68 limited to Gaia and the Cosmos Hub--as secure as possible. 69 70 ### Example Timeline 71 72 The following is an example timeline for the triage and response. The required 73 roles and team members are described in parentheses after each task; however, 74 multiple people can play each role and each person may play multiple roles. 75 76 #### 24+ Hours Before Release Time 77 78 1. Request CVE number (ADMIN) 79 2. Gather emails and other contact info for validators (COMMS LEAD) 80 3. Create patches in a private security repo, and ensure that PRs are open 81 targeting all relevant release branches (TENDERMINT ENG, TENDERMINT LEAD) 82 4. Test fixes on a testnet (TENDERMINT ENG, COSMOS SDK ENG) 83 5. Write “Security Advisory” for forum (TENDERMINT LEAD) 84 85 #### 24 Hours Before Release Time 86 87 1. Post “Security Advisory” pre-notification on forum (TENDERMINT LEAD) 88 2. Post Tweet linking to forum post (COMMS LEAD) 89 3. Announce security advisory/link to post in various other social channels 90 (Telegram, Discord) (COMMS LEAD) 91 4. Send emails to validators or other users (PARTNERSHIPS LEAD) 92 93 #### Release Time 94 95 1. Cut Tendermint releases for eligible versions (TENDERMINT ENG, TENDERMINT 96 LEAD) 97 2. Cut Cosmos SDK release for eligible versions (COSMOS ENG) 98 3. Cut Gaia release for eligible versions (GAIA ENG) 99 4. Post “Security releases” on forum (TENDERMINT LEAD) 100 5. Post new Tweet linking to forum post (COMMS LEAD) 101 6. Remind everyone via social channels (Telegram, Discord) that the release is 102 out (COMMS LEAD) 103 7. Send emails to validators or other users (COMMS LEAD) 104 8. Publish Security Advisory and CVE, if CVE has no sensitive information 105 (ADMIN) 106 107 #### After Release Time 108 109 1. Write forum post with exploit details (TENDERMINT LEAD) 110 2. Approve pay-out on HackerOne for submitter (ADMIN) 111 112 #### 7 Days After Release Time 113 114 1. Publish CVE if it has not yet been published (ADMIN) 115 2. Publish forum post with exploit details (TENDERMINT ENG, TENDERMINT LEAD) 116 117 ## Supported Releases 118 119 The Tendermint Core team commits to releasing security patch releases for both 120 the latest minor release as well for the major/minor release that the Cosmos Hub 121 is running. 122 123 If you are running older versions of Tendermint Core, we encourage you to 124 upgrade at your earliest opportunity so that you can receive security patches 125 directly from the Tendermint repo. While you are welcome to backport security 126 patches to older versions for your own use, we will not publish or promote these 127 backports. 128 129 ## Scope 130 131 The full scope of our bug bounty program is outlined on our 132 [Hacker One program page][hackerone]. Please also note that, in the interest of 133 the safety of our users and staff, a few things are explicitly excluded from 134 scope: 135 136 * Any third-party services 137 * Findings from physical testing, such as office access 138 * Findings derived from social engineering (e.g., phishing) 139 140 ## Example Vulnerabilities 141 142 The following is a list of examples of the kinds of vulnerabilities that we’re 143 most interested in. It is not exhaustive: there are other kinds of issues we may 144 also be interested in! 145 146 ### Specification 147 148 * Conceptual flaws 149 * Ambiguities, inconsistencies, or incorrect statements 150 * Mis-match between specification and implementation of any component 151 152 ### Consensus 153 154 Assuming less than 1/3 of the voting power is Byzantine (malicious): 155 156 * Validation of blockchain data structures, including blocks, block parts, 157 votes, and so on 158 * Execution of blocks 159 * Validator set changes 160 * Proposer round robin 161 * Two nodes committing conflicting blocks for the same height (safety failure) 162 * A correct node signing conflicting votes 163 * A node halting (liveness failure) 164 * Syncing new and old nodes 165 166 Assuming more than 1/3 the voting power is Byzantine: 167 168 * Attacks that go unpunished (unhandled evidence) 169 170 ### Networking 171 172 * Authenticated encryption (MITM, information leakage) 173 * Eclipse attacks 174 * Sybil attacks 175 * Long-range attacks 176 * Denial-of-Service 177 178 ### RPC 179 180 * Write-access to anything besides sending transactions 181 * Denial-of-Service 182 * Leakage of secrets 183 184 ### Denial-of-Service 185 186 Attacks may come through the P2P network or the RPC layer: 187 188 * Amplification attacks 189 * Resource abuse 190 * Deadlocks and race conditions 191 192 ### Libraries 193 194 * Serialization 195 * Reading/Writing files and databases 196 197 ### Cryptography 198 199 * Elliptic curves for validator signatures 200 * Hash algorithms and Merkle trees for block validation 201 * Authenticated encryption for P2P connections 202 203 ### Light Client 204 205 * Core verification 206 * Bisection/sequential algorithms 207 208 [hackerone]: https://hackerone.com/cosmos 209 [tmsec-mailing]: https://berlin.us4.list-manage.com/subscribe?u=431b35421ff7edcc77df5df10&id=3fe93307bc