github.com/number571/tendermint@v0.34.11-gost/SECURITY.md (about)

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