MetaMask is a self-custodial wallet used to manage your identity, digital assets and explore web3.
This program covers Staking in MetaMask Portfolio Validator Staking. Users stake 32 ETH and receive rewards in return.
Deposits, claiming rewards, requesting withdrawals, provisionsing/deprovisioning of validator keys by the operator, and dispatching of rewards/fees are all executed by/via the Kiln On-Chain (v1) smart contracts deployed without a proxy.
In Scope
| Target | Type | Severity | Reward |
|---|---|---|---|
https://etherscan.io/address/0xdc71affc862fceb6ad32be58e098423a7727bebd#code
|
Smart Contract | Critical | Bounty |
https://github.com/kilnfi/staking-contracts/tree/f33eb8dc37fab40217dbe1e69853ca3fcd884a2dcommit hash of the deploy without proxy |
Smart Contract | Critical | Bounty |
Out of scope
| Target | Type | Severity |
|---|---|---|
https://portfolio.metamask.io/ |
Web | None |
There are specific ‘In Scope’ and ‘Out of Scope’ areas that have been identified, however if a vulnerability is found which doesn’t fall into these categories, then please make a submission following the submission guidelines and your submission will be duly triaged.
IN-SCOPE: SMART CONTRACT VULNERABILITIES
We are looking for evidence and reasons for incorrect behavior of the smart contract, which could cause unintended functionality:
- Stealing or loss of funds staked Critical
- Permanent freezing of funds staked Critical
- Theft of unclaimed yield High
- Direct theft of any commission, whether at-rest or in-motion High
- Permanent freezing of unclaimed yield High
- Temporary freezing of funds High
- Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol) Medium
For the avoidance of doubt Critical issues are limited to loss of funds staked (incl. permanent freeze).
OUT OF SCOPE: SMART CONTRACT VULNERABILITIES
Conceptual
- Theoretical vulnerabilities without any proof or demonstration
- Vulnerabilities in Kiln Smart Contracts that do not demonstrate in scope impact
Build
- Old compiler version
- The compiler version is not locked
- Vulnerabilities in imported contracts
- Code style guide violations
- Redundant code
- Impacts on test files and configuration files
- proxy contract related or vulnerabilities relating to contract upgrades
Feature Specific
- Gas optimizations
- Best practice issues and feature requests
- Triggering withdrawal from a Recipient as long as funds go to the right address
Permissions & Malicious User Roles
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (governance, strategist) except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
- The following roles: Operator, Admin and Proxy Admin are trusted to behave properly and in the best interest of the users. They should not be considered as malicious. Reports taking this assumption will be considered invalid.
Network
- Incorrect data supplied by third party oracles
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Impacts from Sybil attacks
- Impacts involving centralization risks
Known issues - known issues will be disclosed publicly: either as an issue on the repository, or via a self-reported bug submission. This helps to streamlined triage and mediation process to prove that an issue is known. Specific known issues can be found on the audit reports.
- Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact
- Make every effort not to damage or restrict the availability of products, services, or infrastructure
- Avoid compromising any personal data, interruption, or degradation of any service
- Don’t access or modify other user data, localize all tests to your accounts
- Perform testing only within the scope
- Don’t exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam
- Don’t spam forms or account creation flows using automated scanners
- In case you find chain vulnerabilities we’ll pay only for vulnerability with the highest severity.
- Don’t break any law and stay in the defined scope
- Any details of found vulnerabilities must not be communicated to anyone who is not a HackenProof Team or an authorized employee of this Company without appropriate permission
- Avoid any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
Proof of Concept (PoC) Requirements
A PoC is required for all Severity levels.
Metamask supports the protection of organizations and hackers engaged in Good Faith Security Research as defined by the U.S. Department of Justice. “Good Faith Security Research” is accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.
We consider Good Faith Security Research to be authorized activity that is protected from adversarial legal action by us. We waive any relevant restriction in our Terms of Use that conflicts with the standard for Good Faith Security Research outlined here.
This means that, for activity conducted while this program is active, we:
(1) Will not bring legal action against you or report you for Good Faith Security Research, including for bypassing technological measures we use to protect the applications in scope; and,
(2) Will take steps to make known that you conducted Good Faith Security Research if someone else brings legal action against you.
You should contact us for clarification before engaging in conduct that you think may be inconsistent with Good Faith Security Research or unaddressed here. We are not able to authorize security research on any other third-party program or infrastructure, and a third party is not bound by this statement.
- Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
- No vulnerability disclosure, including partial is allowed for the moment.
We thank everyone who submits valid reports which help us improve our security. However, only those that meet the following eligibility requirements may receive a monetary reward:
- Not be a resident of any country under U.S. sanctions or any country that does not allow participation in these types of programs
- Be at least 14 years old and have legal capacity to agree to these terms and participate in the Program
- The vulnerability must be a qualifying vulnerability
- Any vulnerability found must be reported no later than 24 hours after discovery and exclusively through hackenproof.com
- You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
- You must not be a former or current employee of Consensys or Kiln or one of its contractor.
- ONLY USE the EMAIL under which you registered your HackenProof account (in case of violation, no bounty can be awarded)
See list of audits. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Known Issues
High Risk
5.1.1 Order of calls to removeValidators can affect the resulting validator keys set
Kiln acknowledged the issue but cited off-chain monitoring, legal agreements with operators, infrequent use of removeValidators, and desire to minimize changes to on-chain v1 codebase
Spearbit May 2023
High Risk
5.1.2 Third-party operator could bypass FeeRecipient contract
Kiln acknowledged: Off-chain monitoring, legal agreements with operators in place
No way to enforce at execution layer level
Spearbit May 2023
High Risk
5.1.3 An operator can hijack another operator's keys and signatures to register its own fee recipient
Kiln acknowledged: Off-chain monitoring, avoiding BLS manipulation, legal agreements with operators
Spearbit May 2023
High Risk
5.1.4 Deposit front-running
Kiln acknowledged: Off-chain monitoring, legal agreements with operators
Spearbit May 2023
High Risk
Incorrect Priviliges setOperatorAddresses
Consensys acknowledged this as intended system design as the fee recipient and system_admin can be the same wallet.
Diligence August 2023
Medium Risk
Unconstrained Snapshot While Setting Operator Limit
Consensys acknowledged as lower risk to current implementation as the current number of operators is set to 1.
Diligence August 2023
Medium Risk
Missing Input Validation
Consensys acknowledged as lower risk to current implementation as the current number of operators is set to 1.
Diligence August 2023
Medium Risk
Hardcoded Operator Limit Logic
Consensys acknowledged as lower risk to current implementation as the contract is not deployed with a proxy and therefore is not upgradeable.
Diligence August 2023
Medium Risk
StakingContract - PubKey Length Checks Not Always Enforced
Consensys acknowledged as lower risk and a potential enhancement
Diligence August 2023
Medium Risk
Unpredictable Behavior Due to Admin Front Running or General Bad Timing
Consensys acknowledged as lower risk due to owning sys_admin and the deployed contract is not upgradeable.
Diligence August 2023
Medium Risk
Potentially Uninitialized Implementations
Consensys acknowledged and considers malicious operators out of scope
Diligence August 2023
Medium Risk
Operator May DoS the Withdrawal or Make It More Expensive
Consensys acknowledged and considers malicious operators out of scope
Diligence August 2023
Medium Risk
ProxyAdmin May Cause DoS for SYS_ADMIN
Consensys acknowledged and considers proxy admin out of scope as the contract is not deployed with a proxy.
Diligence August 2023
The total rewards paid under this program will be capped to the maximum reward as outlined in Rewards (Range of bounty in ETH). In the event that multiple bug reports are submitted that exceed this amount, the rewards will be provided on a first come first served basis.
Reward Calculation for Critical Severity Reports
For critical Smart Contract vulnerabilities that result in direct theft or permanent freezing of funds, the reward amount is 10% of the funds directly affected up to the maximum outlined in the Rewards per Severity Table. The calculation of the amount of funds at risk is based on the time and date the bug report is submitted. However, a minimum reward as outlined in the Rewards per Severity Table is to be rewarded in order to incentivize security researchers against withholding a bug report.
Reward Calculation for High Severity Reports
For high Smart Contract vulnerabilities that result in direct theft or permanent freezing of unclaimed yield or commission, or the temporary freezing of unclaimed yield for more than 24hrs, the reward amount will be capped at 100% of the funds affected, up to the maximum outlined in the Rewards per Severity Table. However, a minimum reward as outlined in the Rewards per Severity Table is to be rewarded in order to incentivize security researchers against withholding a bug report.
Repeatable Attack Limitations
In cases of repeatable or chained attacks for smart contract bugs, the initial vulnerability will be treated as one submission for the repeated or chained attack vector.