Skip to content
This repository has been archived by the owner on Oct 8, 2023. It is now read-only.

Latest commit

 

History

History
233 lines (163 loc) · 19.2 KB

README.md

File metadata and controls

233 lines (163 loc) · 19.2 KB
Raw

Optimism Bedrock Update contest details

Reward structure

  • $120k contest pot ($70k in OP tokens, 50k USDC)
  • 40k USDC to Lead Senior Watsons (obront and Trust)
  • $6k USDC allocated to judging ($3.5k in OP tokens, 2.5k USDC)
  • The exchange rate of OP tokens will be the 30-day weighted average beginning at the start date of the contest and ending 30 days after the start date of the contest, using a well-known exchange rate aggregator such as CoinGecko
  • All rewards are guaranteed in this contest, there are no Medium/High severity thresholds to unlock more of the pot

Judging changes from the previous Optimism contest

  • Issue de-duplication and initial judging will be handled by a Lead Judge (TBD) approved by Sherlock and Optimism.
  • Final decisions on judging will be made by Sherlock (in consultation with the Lead Judge and Optimism).
  • Judging criteria for High and Medium issues will attempt to mirror the judging criteria of the last Optimism contest. In the event of gaps in the previous judging criteria, the Sherlock judging rules will be consulted.
  • Low severity issues are not accepted
  • Similar to the first contest, this contest will not count towards Leaderboard rankings for any Watsons (due to non-Solidity code, etc.).

On-chain context

DEPLOYMENT: Ethereum and Optimism Mainnet
ERC20: All tokens with regular behavior
ERC721: All tokens with regular behaviour
ERC777: none
FEE-ON-TRANSFER: none
REBASING TOKENS: none

System context

The previous competition looked at contracts deployed on the Goerli network.

As we have not yet upgraded the contracts on Goerli, this compettion will focus on the source code listen in the Scope section below.

Audit scope

The key components of the system can be found in our monorepo at commit 9b9f78c661, as well as in the op-geth repo at commit 7eee103098

Resources

The following resources will be useful for helping to understand the system.

Roles

The following table outlines all the roles and their permissions in the system

Role Capability
L2 ProxyAdmin Owner Can instantly upgrade all L2 contracts.
L1 ProxyAdmin Owner Can instantly upgrade all L1 contracts.
Challenger Can call deleteL2Outputs() in the event of fault.
MSD Controller Controls the Migration SystemDictator contract.
System Config Owner Can modify system config values.
Proposer Can propose new L2 Outputs.
Sequencer Can submit new transaction batches.
Guardian Can pause and unpause the Portal.

Known issues

The following issues are known and will not be accepted as valid findings:

  1. There is an edge case in which ETH deposited to the OptimismPortal by a contract can be irrecoverably stranded:

    When a deposit transaction fails to execute, the sender's account balance is still credited with the mint value. However, if the deposit's L1 sender is a contract, the tx.origin on L2 will be aliased, and this aliased address will receive the minted on L2. In general the contract on L1 will not be able to recover these funds.

    We have documented this risk and encourage users to take advantage of our CrossDomainMessenger contracts which provide additional safety measures.

  2. Sherlock #035 Memory amplification with small but invalid P2P messages

    The fix for this issue is a WIP, and will be addressed prior to mainnet launch.

    • NOTE: AIMING TO COMPLETE BEFORE START OF THE COMP.

  3. Sherlock #209, #277: Deposit grieffing by filling up the MAX_RESOURCE_LIMIT

    This issue is mitigated by PR 5064, which does not completely resolve the issue but does increase the cost of a sustained grieffing attack. A more complete fix will require architectural changes.

  4. There are various 'foot guns' in the bridge which may arise from misconfiguring a token. Examples include:

    • Having both (or neither of) the local and remote tokens be OptimismMintable.
    • Tokens which dynamically alter the amount of a token held by an account, such as fee-on-transfer and rebasing tokens. To minimize complexity our bridge design does not try to prevent all forms of developer and user error.

  5. When running in non-archive mode op-geth has difficulty executing deep reorgs. We are working on a fix.

Prior Sherlock findings and fixes

The following is a list of findings from the previous Sherlock Audit, along with their fixes:

  • Sherlock #282: Client will accept invalid blocks from gossip channels due to insufficient L1BlockInfo decoding
  • Sherlock #087: Users withdrawals can be permanently locked (via the reentrancy guard)
  • Sherlock #080, #096, #158, #297: Withdrawals with high gas limits can be bricked by a malicious user, permanently locking funds
  • Sherlock #109: Malicious user can finalize other’s withdrawal with less than specified gas limit, leading to loss of funds
  • Sherlock #298: Incorrect implementation of the _isCorrectTokenPair function
  • Sherlock #279: Frame parsing accepts fully missing fields
  • Sherlock #026, #055, #057: Funds are frozen if send from L1 -> L2 while the L2XDM is paused
  • Sherlock #011, #105, #113, #189, #218, #223, #232: Message passer DoS in migration
  • Sherlock #235: Function MigrateWithdrawal() may set gas limit too high for old withdrawals
  • Sherlock #177: Crafted p2p spam can render nodes permanently unable to process L2 blocks
  • Sherlock #051: Cannot bridge native L2 tokens using withdraw/withdrawTo functions
  • Sherlock #053 and #058: Withdrawal transactions can get stuck if output root is reproposed

What to look for

In order to guide you, we've attempted to outline as clearly as possible the the types of attacks we'd like you to pursue. Issues which do not match those described below will be considered, but are not guaranteed to be accepted.

The remainder of this document is subdivided into sections based on the type of attack and then outlines the different severity attacks with

Client node vulnerabilities

The critical client node components are the op-node and op-geth services, which are written primarily in Go.

High

  • Bypass the deposit fee logic, causing the sequencer to improperly mint ETH on Optimism
    • Explanation: The op-node service reads events which are emitted by the Optimism Portal contract on L1, and parses those events in order to create deposit transactions which can mint ETH on L2. This attack would require fooling this logic into minting ETH, without actually having to deposit ETH into the Optimism Portal contract.
  • The Sequencer/Batcher should not be able to trick verifiers into accepting invalid blocks into their safe chain.

Medium

  • Consensus failures
    • Explanation: There is one sequencer (running the op-node and batcher services) submitting transaction batches to L1, but many verifier op-nodes will read these batches and check the results of its execution. The sequencer and verifiers must remain in consensus, even in the event of an L1 reorg. In addition, verifiers may operate in two different modes meaning that they either read “unsafe” blocks from the Sequencer, or only derive the L2 state from L1. Verifiers in either of these modes should all eventually agree about the finalized head. Similarly, a verifier which is syncing the chain from scratch should agree with a verifier which has been running and is likely to have handled L1 reorgs.
  • DoS attacks on critical services
    • Explanation: Any untrusted inputs which can result in a crash or otherwise cause a denial of service in the op-node or op-geth. Attack surfaces include but are not limited to P2P payloads, RPC payloads, and blockchain state. Moreover, the network should even be robust against batches which could be posted by a malicious sequencer.

EVM equivalence vulnerabilities

Bedrock’s design aims for EVM equivalence, meaning that smart contract developers should be able to safely deploy the same contracts to Optimism as they would on Ethereum, without concern for differences in the execution.

An example of a bug which occurred in an earlier version of Optimism was an ETH inflation attack which resulted from a difference between the semantics of SELFDESTRUCT in Optimism vs. Ethereum.

High

Findings that break contracts in a way that could cause people to lose funds and could be experienced with relatively high frequency by the average developer, or allows you to mint ETH, modify state of other contracts, generally cause loss of funds.

Medium

Findings that break contracts but are difficult to trigger and only impact a very contrived or unusual contract, suggesting that a developer would have to go significantly out of their way to trigger the issue.

Bridge vulnerabilities

Naturally the security of our bridging contracts is critical as it holds all assets deposited from L1, and controls the creation of assets on L2.

High

  • Successfully replay a previously completed withdrawal
    • Explanation: Because our bridge contracts are being upgraded from a previous state, it’s possible that a misconfiguration could cause previously completed withdrawals to be replayed. This attack class is similar to the Nomad bridge vulnerability.
  • Forge a withdrawal proof such that you can prove an invalid withdrawal
    • Explanation: We have a Solidity implementation of the Merkle Patricia Tree. Can you trick it into verifying the existence of a withdrawal which does not exist? This type of attack would be similar to that of the Binance Bridge attack.
  • Bypass the two step withdrawal proof logic
    • Explanation: In order to mitigate against possible bugs in our withdrawal proof, we’ve introduced a two step withdrawal process which requires users to prove their withdrawal at the beginning of the 7 day waiting period.
  • Permissionlessly prevent another user from depositing or withdrawing.
    • Explanation: Several findings in the previous Sherlock audit (see findings 80, 87, and 109) identified attacks which would allow an arbitrary user to lock up another user's withdrawal (including the associated data and assets). This would have required an upgrade to intervene and release the withdrawals. We're interested in similar attacks on the deposit path as well.

Medium

  • A system user preventing a user from depositing or withdrawing
    • Explanation: Two findings in the previous Sherlock audit (see findings 26 and 53) identified attacks which would allow a system user (ie. the Proposer or Messenger Owner) to lock up a user's withdrawal (including the associated data and assets). This would have required an upgrade to release the withdrawals. We're interested in similar attacks on the deposit path as well.
  • Temporarily preventing a user from depositing or withdrawing.
    • Explanation: A findings in the previous Sherlock audit (see finding 209) identified an attack which would allow an arbitrary user to temporarily prevent another user from depositing (including the associated data and assets) using a grieffing attack. This attack would be costly sustain, but also a significant headache for depositors. We're interested in similar attacks on the withdrawal path as well.

Generic smart contract issues

Some of the most common smart contract vulnerabilities also apply to our system and are critically important to mitigate.

High

  • Authorization bypass issues enabling an attacker to take actions which should be restricted to one of the system’s special actors, ie. Proposer, Challenger or Batch Submitter
  • Upgradability proxy and configuration issues enabling an attacker to re-initialize, take control
  • Unexpected reverts causing a system lockup. For example getting the system into a state where any call to a function would revert, possible due to an over/underflow, or other issue.

Medium

  • Attacks, including DoS and griefing, leading to temporary freezing of funds in the bridge.

Migration attacks or bugs

During the migration from the legacy system to Bedrock, the Optimism network is temporarily halted, and undergoes a process of ‘state surgery’, which directly modifies the bytecode and storage of certain contracts.

Migration attacks would involve putting the legacy system into a pre-migration state such that our migration scripts will result in any of the following:

High

  • ETH is minted or destroyed as a result of the migration.

Medium

  • Contract state which does not match the legacy system (aside from that which is clearly intended to be modified)
    • If this results in loss of funds or another high severity issue, it will be considered as such.
  • Attacks which enable an arbitrary user to halt the migration process (as in finding 11).