Security Disclosure: Security Vulnerabilities in Optimism Fraud Proof System

Author: Ed Felten, Co-founder of Offchain Labs Source: medium Translation: Shan Ouba, Golden Finance

On March 22, the Offchain Labs team disclosed to the OP Labs team two serious security vulnerabilities we found in the Optimism fraud proof system they deployed on the testnet. We provided the OP Labs team with demonstration exploit code for the attacks. On March 25, OP Labs confirmed the validity of both issues.

We coordinated our disclosure with the OP Labs team. OP Labs asked us to hold off on publicly disclosing these vulnerabilities until they are resolved. Late yesterday (April 25), the Optimism testnet was updated, and today we disclosed these vulnerabilities for the first time.

These vulnerabilities allow a malicious party to force the OP Stack fraud proof mechanism to accept a fraudulent chain history, or to prevent the OP Stack fraud proof mechanism from accepting the correct chain history. These issues stem from flaws in the way the OP fraud proof design handles timers.

The result is that the fraud proof system does not improve safety guarantees over an approach that relies entirely on emergency intervention by the Security Council.

Nature of the Vulnerabilities

Timers are one of the most subtle aspects of interactive fraud proof design. An adversary may not make a move in the challenge game at all, so at some point the protocol needs to declare that a player who has not moved has lost the game on timeout. But an adversary can also use censorship attacks on the parent L1 chain (e.g. Ethereum) to prevent honest parties from participating in the game.

If time passes and a player has not moved, the protocol cannot tell whether that player is being censored, or is a bad actor who is staying silent and pretending to be censored. (In both cases, the protocol sees only “radio silence” from the players.) Therefore, the protocol must give honest players enough time leeway so that they don’t lose due to censorship, while preventing malicious players from stalling the protocol for too long.

For example, in a one-on-one challenge protocol, where there is one player on each side of the dispute, the approach used by the protocol currently deployed by Arbitrum works very well. Here’s an intuitive way to understand the approach: each player gets a “time point” when it’s the other players’ turn to move, and if a player has accumulated 7 days of time points, the challenge is won for time. The idea is that if a player is “late” for a total of 7 days, it’s not plausible that this delay was entirely due to censorship, so the player can be considered dishonest—and thus can be safely declared the loser. This makes the one-on-one protocol safe from censorship for up to 7 days.

This approach works well when there is only one player on each side of the dispute. But when you allow many players, as Optimism does, it’s less obvious how to manage time points. It is tempting to divide the players into two teams, one for each side of the dispute, each with time points. But you need to be careful because of traitor attacks, where a malicious party pretends to be honest for a while, only to stab their honest "teammate" in the back at the worst possible moment.

The OP protocol, originally deployed on testnet, is vulnerable to such traitor attacks because it allows traitors to receive undeserved time bonuses. This would allow a malicious actor to win a fraud proof game that they should lose, thereby accepting a fraudulent chain history or rejecting the correct chain history.

These are difficult problems to solve, and while OP's original design was subject to subtle attacks, they made some changes to their timer handling code to address the demonstration vulnerability we provided. We have not yet performed a security analysis of their modified protocol.

Dealing with timers, traitors, and other attacks

Fraud-resistant protocols, especially their timing aspects, are very difficult to design. That’s why our BoLD protocol comes with a technical paper that provides a detailed threat model and proof that the BoLD protocol is not vulnerable to such traitor attacks. Given the complexity and subtlety of these issues, we felt it was essential to have a clear threat model and security proof to ensure that potential attacks are not present. In fact, in the process of creating the proof, we discovered and fixed multiple issues in the BoLD protocol.

Original Security Disclosure

Here is an extended excerpt from the disclosure we sent to OP Labs on March 22:

We (the Offchain Labs team) have discovered that the current version of the OP Stack fault proof system has serious systemic flaws. This document describes these flaws and provides example exploit code for your reference.

These flaws would allow an adversary to undermine the safety and liveness of the chain by having the protocol accept fraudulent claims, reject correct claims, or create disputes that cannot be resolved within the L1 gas limit. [Note (April 26): The third issue (unresolvable disputes) has been made public and documented, so we will remove further mentions of it.]

We believe that your current protocol would expose user funds to a very high risk if deployed on mainnet.

Nature of the flaws

Some of the flaws appear to stem from how timers are managed in the error-proofing system. In short, inheriting timers from grandparent claims allows a claim made by a malicious actor to inherit timer credit from a claim previously made by an honest actor, thereby artificially inflating the timer credit of the malicious claim to the point where the malicious actor can win the challenge. For example, a malicious actor could arrange to inherit timer credit that is only slightly less than the credit required to claim victory; then claim a win due to timeout before any other party is able to react

Exploitation Examples

Below is a set of example exploits that demonstrate these attacks.

The first vulnerability ( test_exploit_last_second_challenge) allows an attacker to defeat honest claims.

The second vulnerability ( test_exploit_last_second_defend) allows an attacker to accept fraudulent claims.

These exploits appear to work on the latest version of the OP stack fraud proof system at the time of submission, 96a269bc793fa30c3e2aa1a8afd738e4605fa06e