Skip to content

Latest commit

 

History

History
144 lines (98 loc) · 5.32 KB

SECURITY.adoc

File metadata and controls

144 lines (98 loc) · 5.32 KB
Raw

Security Policy

Supported Versions

A given release of the Solidity code base includes all deployed contracts that are supported---older contracts (generally contracts that no longer have KEEP stake associated) that are no longer included in the release package are no longer supported for security updates.

Note that tBTC is built in part on top of the Keep network, whose security policy is similar and described at https://github.com/keep-network/keep-core/tree/master/SECURITY.adoc.

Reporting a Vulnerability

To report a vulnerability, please email the contact listed at https://tbtc.network/security.txt and include:

  • The affected component (tBTC).

  • A text description of the vulnerability.

  • Preferably, steps to reproduce the issue.

  • If available, an initial assessment of impact, ideally using the Common Vulnerability Scoring System. There is a calculator to help. Note that for CVSS purposes, the tBTC team generally treats fund compromise as a loss of Confidentiality.

  • If desired, a suggestion on how to fix the issue.

  • If reporting a sensitive vulnerability in an encrypted message, please include a key for encrypting replies, or a secure medium to contact you. Note that for various reasons, the tBTC team prefers email and Keybase, but can work with Signal and Telegram on a case-by-case basis. Please always file an initial report via email, even if follow-up is handled via a different channel.

Please also note the suggestions on email structure below, and prefer to encrypt particularly sensitive vulnerabilities with one of the keys listed at https://tbtc.network/security.txt .

Timelines

The tBTC team will make a best effort to respond to a new report within 48 hours. This response may be a simple acknowledgement that the report was received, or may be an initial assessment from the team. Unless the report is assessed as irrelevant or incorrect, this response will include expected next steps and communication time frames from the tBTC team.

Assessments

The tBTC team will try to make an initial assessment of a bug’s relevance, severity, and exploitability, and communicate this back to the reporter.

The tBTC team does have a bug bounty available, denominated in KEEP, which is dispensed on a case-by-case basis.

Email structure

For simplicity, we recommend a standard flow for the vulnerability report:

SUMMARY

A summary of the issue.

SAMPLE EXPLOIT STEPS

A series of steps that can be used to exploit this vulnerability.

IMPACT (optional)

If available, an initial assessment of impact. Usage of the
https://www.first.org/cvss/[Common Vulnerability Scoring System] is
encouraged. There is a https://www.first.org/cvss/calculator/3.1[calculator]
to help. Note that for CVSS purposes, we generally treat fund compromise as a
loss of Confidentiality.

DETAILS

A detailed description of the vulnerability, including any information that
can be used to better understand and/or reproduce the vulnerability.
Preferably include code to reproduce.

SUGGESTED REMEDIATION (optional)

If desired, a suggestion on how to fix the issue.

FOLLOWUP INFO (optional)

If this is an encrypted message, include your PGP key for an encrypted reponse.
Alternatively, you can include a Keybase handle,  Signal number, or a Telegram
handle (in order of the tBTC team's preference).

Email subject

To help in filtering reports, please use an email subject in this format, omitting severity if you are not certain of impact:

[SEVERITY] [component] issue: [brief summary]
Example 1. Sample Vulnerability Report Email (adapted from keep-network/tbtc#664)

Subject: [8.6 HIGH] Solidity contracts issue: Incorrect handling of Bitcoin addresses can lead to deposit redemption failure

Body:

SUMMARY

Funding transactions that use p2pkh are accepted during funding but can be used to trigger ECDSA fraud during redemption.

SAMPLE EXPLOIT STEPS

Eve creates a deposit, funds it using a P2PKH or P2SH output, and requests redemption. The signing group is unable to provide a redemption proof, and eventually Eve seizes the group’s bonds.

IMPACT

We consider this an 8.6 on the CVSS 3.1 scoring scale, as it can compromise signer funds, and can lead to signer fund loss that is value-positive for the attacker. Attacker profit is ~50% the value of the funds they are willing to put into the attack, while per-signer loss is ~12.5% of the funds the attacker puts into the attack.

CVSS 3.1 vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/CR:M

DETAILS

When providing a funding proof, three types of outputs are accepted: P2WPKH, P2PKH, and P2SH outputs. The system is designed to handle the first and fails for the second and third.

If a P2PKH output is provided, the signing group is able to generate a scriptSig which can spend the output. However, that will trigger the ECDSA fraud flow as the signature wasn’t authorized.

If a P2SH output is provided, then the public key of the keep will be interpreted as a script. This most likely results in a locked output.

SUGGESTED REMEDIATION

Disallow P2PKH and P2SH outputs when providing funding proofs.

FOLLOWUP INFO

Please encrypt replies to PGP key https://keybase.io/shadowfiend/pgp_keys.asc, or reply via Keybase at https://keybase.io/shadowfiend .