[FINAL] Upgrade #1: Bedrock Protocol Upgrade - v2

📃Other Proposals Protocol Upgrade
3

Hey folks, Maurelian from OP Labs here to provide a more detailed rundown on the final results of the Sherlock audit contest.

First to provide some context: an audit contest is a variation on a typical smart contract security audit, in which a total reward pot is posted to incentivize auditors to look for issues in a codebase. The rewards are paid out based on the number and severity of findings. You can find more details about audit contests in general in the Sherlock docs and about the Bedrock contest in particular in the contest description.

Recap of the numbers

  • A total reward of $720k was posted
  • 333 people signed up for the contest
  • 314 issues were submitted in total (note: this does not mean there were 314 unique issues)
  • 60 people submitted at least one issue

Summary of Findings

After reviewing all 314 issues, identifying duplicates, and assigning severities, we’ve identified:

  • 3 High severity findings (which you can see here)
  • 11 Medium severity findings (which you can see here)

You may notice that the numbers in this update are different from Ben’s previous update.

This is because the audit contest has recently completed the escalation period, during which auditors could stake funds on any issues they feel have been misjudged. This has led to a re-review of 32 issues by the Sherlock team with support from OP Labs.

Importantly, one of the high severity findings we previously reported has since been identified as a false positive.

The ‘evolving understanding’ of the results is a necessary by-product of the audit competition model, as a significant effort was required to understand and validate the many reports we received.

Next, I’ll walk through the details of the various issues. Each of these issues has already either been fixed, or else has a fix in progress.

Overview of high severity findings

The high severity findings were all of a similar nature, namely permissionless griefing attacks which would allow any malicious user to interfere with a victim’s withdrawals from L1 to L2, causing their assets to be locked in the system. If the contracts were not upgradable, the locked assets would be irrecoverable.

Relevant to each of the high severity findings is the fact that all withdrawal transactions are sent via the OptimismPortal, which finalizes the withdrawal regardless of the result (so if the call from the portal fails, it cannot be ‘replayed’). In order to provide additional safety guarantees for most users, CrossDomainMessenger contracts are included in the codebase, which are designed to ensure that deposits and withdrawals sent using these contracts can always be retried.

It is also important to note that finalizing a withdrawal transaction is permissionless, ie. Bob can finalize Alice’s withdrawals and vice versa.

With that context, the specifics of each attack are as follows:

High severity finding 1: Reentrancy lock up

This finding specifically affects withdrawals that are sent via the messenger contracts. It would enable an attacker to lock up users’ withdrawals one at a time, meaning that they could identify a specific withdrawal and ensure that it is finalized in the OptimismPortal, but cannot be replayed by the L1CrossDomainMessenger. Details can be found in issue 87.

High severity finding 2: High gas limit lock up

This finding specifically affects withdrawals which have a very high gas limit (greater than 11,245,655 gas). In such cases an attacker can finalize the withdrawal but ensure that slightly less than the requested gas amount is forwarded. This is an edge case, but breaks the important guarantee that the amount of gas specified for the withdrawal on L2 will be made available to it on L1. Details can be found in issue 109.

High severity finding 3: Low gas limit lock up

This finding specifically affects withdrawals with gas limits set close to the lower bound of what is required to finalize it on L1. In such cases, an attacker can finalize the withdrawal with just enough gas to ensure that is is finalized, but not enough for the call to succeed. Details can be found in issue 80.

Overview of Medium severity findings

These findings (which you can see here) fall into 4 categories:

  1. Griefing
    1. Permissioned withdrawal griefing, would allow the Proposer to lockup a withdrawal, or the Challenger to invalidate finalized withdrawals. These attacks are similar to the High severity ‘permissionless griefing’ attacks except that they require increased authorization. Details can be found in issues 53, 57, 75 and 138.
    2. Deposit griefing, which would allow a malicious user to interfere with other users’ deposits. Details can be found in issue 277.
  2. Errors in the migration process. Issue 105 would cause the migration process to halt thus increasing down time. Issue 235 may result in some pre-bedrock withdrawals being locked in the system.
  3. DoS attacks on the op-geth or op-node services. Details can be found in issues 71, 177, 276, and 279
  4. Token compatibility issues. Details can be found in issue 220.

Next steps

Each of the identified issues has already either been fixed, or else has a fix in progress.
We are now performing our own internal audit, using these findings to:

  1. Retroactively search for similar issues;
  2. Identify testing and process improvements which would have prevented these issues from being introduced; and
  3. Create monitoring to ensure that we can detect and respond to similar issues should they occur in production.

We will also be conducting a follow up audit, and will announce the date as soon as it is confirmed.

14 Likes