0xdeadbeef - Attacker can cause migration to fail or be inaccurate

[github-actions]

0xdeadbeef

high

Attacker can cause migration to fail or be inaccurate

Summary

Migration starts from L1 by running a series of steps in SystemDictator.
A hacker can monitor L1 to identify the start of the migration and then create an L2 withdrawal after the witness data is already created.

Because the L2 has an additional message in storage, that is not present in the generated witness data - the migration will fail in the PreCheckWithdrawals if the noCheck flag is enabled.

If the noCheck is disabled, the protocol risks losing "legitimate" withdrawals and therefore not accurate.

Vulnerability Detail

When migrating to bedrock SystemDictator is used to execute each step on L1 and db_migrate is used to upgrade L2.

A hacker can identify when the start of the migration by monitoring SystemDictator and specifically front-running step2 which shuts down the network by setting DTL_SHUTOFF_BLOCK.

https://github.com/sherlock-audit/2023-01-optimism/blob/main/optimism/packages/contracts-bedrock/contracts/deployment/SystemDictator.sol#L197-L217

When front-running step2, the hacker can immediately call issue the legacy sendMessage (L2CrossDomainMessenger) or passMessageToL1 (OVM_L2ToL1MessagePasser) to add another withdrawal on L2 that is not included in the witness data that should already be generated for the migration.

During the migration, there is a check called PreCheckWithdrawals that is called if the noCheck flag is called. The function checks that the witness data withdrawals from L2 match the storage slot of OVM_L2ToL1MessagePasser

https://github.com/sherlock-audit/2023-01-optimism/blob/main/optimism/op-chain-ops/crossdomain/precheck.go#L52-L58

If it is not the case, an error will bubble up and the migration will stop.

Impact

The vulnerability will cause the migrator to fix the witness data which would require more time, testing and research or call the migration script without the noCheck which will risk not migrating "legitimate" last minute withdrawals.

Even if the witness data is fixed and the system will be "unpaused" if the migration script fails and the system "reverts" by calling exit in SystemDictator, a hacker can repeat the same process and cause the migration to fail again.

Optimism will have a hard time to identify if the actions are performed by an attacker or a legitimate user

Code Snippet

In the description

Tool used

Manual Review

Recommendation

In order to create accurate witness data, create it after the DTL is paused and after the protocol stops accepting new blocks on L2. This will not allow anyone to change the state of the L2 after the witness data is created.

Duplicate of #105

[rcstanciu]

Comment from Optimism

---

Description: DoS during the migration process

Reason: Good catch if accurate. Just need validation. Would call this a medium severity if so.