Panic in MIPS VM Could Lead to Unchallengeable L2 Output Root Claim

[c4-bot-2]

Lines of code

https://github.com/code-423n4/2024-07-optimism/blob/70556044e5e080930f686c4e5acde420104bb2c4/packages/contracts-bedrock/src/dispute/FaultDisputeGame.sol#L883-L895 https://github.com/code-423n4/2024-07-optimism/blob/main/op-node/rollup/derive/channel.go#L169-L205

Vulnerability details

Impact

Suppose we have a situation where the MIPS geth goes wrong and always panics. The vmStatus can only be either UNFINISHED or PANIC.

In the current execution bisection game system, the UNFINISHED state can not be used as the root claim; the PANIC state can always be attacked. So we can counter every bisection game at SPLIT_DEPTH + 1; none of the claims at SPLIT_DEPTH are challenged. Inductively, claims agreeing with SPLIT_DEPTH are not challengable.

In the current configuration, SPLIT_DEPTH is set to 30, so we can deny any dispute against the root claim at depth 0. If that were to happen, the state of the L2 output root could be hijacked and unrecoverable.

It's unclear if there are easy methods to trigger panic in the MIPS VM.

One possible way is to leverage the privilege, as the batcher is currently controlled by a centralized trusted entity. Ordinary users cannot construct the batches and channels for the rollup, but the batcher can freely set the payload blob to L1.

https://github.com/code-423n4/2024-07-optimism/blob/main/op-node/rollup/derive/channel.go#L169-L205

A malicious batcher could compress a huge amount of zero blobs, upload them to L1, and force the MIPS VM to decompress them. Considering the limited memory resources of the MIPS VM and the absence of garbage collection in the MIPS go-ethereum, the VM could be very easily corrupted.

Recommended Mitigation Steps

Set the split_depth to an odd number.

Assessed type

DoS

[Inphi]

This is valid. Note that an implicit assumption of the FaultDisputeGame is that the program being verified must be not contain bugs or panic unexpectedly. But we have not documented this assumption clearly. So we would still like to acknowledge this report.

Also note that there are other problems introduced by adjusting the split depth to fix this. Really fixing this will require a multi-proof architecture, to mitigate against a single faulty program taking down the system, rather than tweaks to a dispute game.

[c4-judge]

zobront marked the issue as satisfactory

[c4-judge]

zobront marked the issue as selected for report