github.com/badrootd/celestia-core@v0.0.0-20240305091328-aa4207a4b25d/SECURITY.md (about)

     1  # Security
     2  
     3  ## Reporting a Bug
     4  
     5  As part of our Coordinated Vulnerability Disclosure Policy (link will be added
     6  once this policy is finalized for CometBFT), we operate a [bug
     7  bounty][hackerone]. See the policy for more details on submissions and rewards,
     8  and see "Example Vulnerabilities" (below) for examples of the kinds of bugs
     9  we're most interested in.
    10  
    11  ### Guidelines
    12  
    13  We require that all researchers:
    14  
    15  * Use the bug bounty to disclose all vulnerabilities, and avoid posting
    16    vulnerability information in public places, including GitHub Issues, Discord
    17    channels, and Telegram groups
    18  * Make every effort to avoid privacy violations, degradation of user experience,
    19    disruption to production systems (including but not limited to the Cosmos
    20    Hub), and destruction of data
    21  * Keep any information about vulnerabilities that you’ve discovered confidential
    22    between yourself and the CometBFT engineering team until the issue has been
    23    resolved and disclosed
    24  * Avoid posting personally identifiable information, privately or publicly
    25  
    26  If you follow these guidelines when reporting an issue to us, we commit to:
    27  
    28  * Not pursue or support any legal action related to your research on this
    29    vulnerability
    30  * Work with you to understand, resolve and ultimately disclose the issue in a
    31    timely fashion
    32  
    33  ## Disclosure Process
    34  
    35  CometBFT uses the following disclosure process:
    36  
    37  1. Once a security report is received, the CometBFT team works to verify the
    38     issue and confirm its severity level using CVSS.
    39  2. The CometBFT team collaborates with the Gaia team to determine the
    40     vulnerability’s potential impact on the Cosmos Hub.
    41  3. Patches are prepared for eligible releases of CometBFT in private
    42     repositories. See “Supported Releases” below for more information on which
    43     releases are considered eligible.
    44  4. If it is determined that a CVE-ID is required, we request a CVE through a CVE
    45     Numbering Authority.
    46  5. We notify the community that a security release is coming, to give users time
    47     to prepare their systems for the update. Notifications can include forum
    48     posts, tweets, and emails to partners and validators.
    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 CometBFT dependencies to use these releases,
    52     and then themselves issue new releases.
    53  8. Once releases are available for CometBFT, Cosmos SDK and Gaia, we notify the
    54     community, again, through the same channels as above. We also publish a
    55     Security Advisory on GitHub and publish the CVE, as long as neither the
    56     Security Advisory nor the CVE include any information on how to exploit these
    57     vulnerabilities beyond what information is already available in the patch
    58     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 CometBFT 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 (CometBFT ENG, CometBFT LEAD)
    82  4. Test fixes on a testnet  (CometBFT ENG, COSMOS SDK ENG)
    83  5. Write “Security Advisory” for forum (CometBFT LEAD)
    84  
    85  #### 24 Hours Before Release Time
    86  
    87  1. Post “Security Advisory” pre-notification on forum (CometBFT 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 CometBFT releases for eligible versions (CometBFT ENG, CometBFT
    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 (CometBFT 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 (CometBFT 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 (CometBFT ENG, CometBFT LEAD)
   116  
   117  ## Supported Releases
   118  
   119  The CometBFT 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 CometBFT, we encourage you to
   124  upgrade at your earliest opportunity so that you can receive security patches
   125  directly from the CometBFT 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  * Mismatch 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