Impact (Permissionless mode)
This attack allows any proposer to halt withdrawals by refusing to advance the l2 root. This is fixable with guardian intervention, but causes a significantly degraded experience for users.
No user funds are at risk. A malicious proposer is only able to halt the chain, not prove withdrawals against arbitrary malicious state roots.
Impact (Permissioned mode)
In permissioned mode, permissioned proposers are already able to halt withdrawals by simply refusing to propose output roots. For this reason, we believe that this vulnerability only affects permissionless mode OP-Succinct deployments.
Technical analysis
The issue comes from the following check in the client executor (link)
if boot.agreed_l2_output_root == boot.claimed_l2_output_root {
info!(
target: "client",
"Trace extension detected. State transition is already agreed upon.",
);
return Ok((boot_clone, None));
}
If the starting l2 output root is the same as the ending l2 output root, then the proposer can prove a transition between any l2 blocks. In other words, a range proof of (starting_l2_block_number, starting_l2_root, ending_l2_block_number, starting_l2_root) will incorrectly verify.
Mitigation
This vulnerability can be fixed by removing the shortcut, as in this pr.
Recommendations
If you're running v2.3.0 permissionless mode, switch to permissioned mode.
Upgrade to v3.0.0 when it is audited and released.
Acknowledgements
Thanks to cergyk for finding and disclosing this vulnerability.
Impact (Permissionless mode)
This attack allows any proposer to halt withdrawals by refusing to advance the l2 root. This is fixable with guardian intervention, but causes a significantly degraded experience for users.
No user funds are at risk. A malicious proposer is only able to halt the chain, not prove withdrawals against arbitrary malicious state roots.
Impact (Permissioned mode)
In permissioned mode, permissioned proposers are already able to halt withdrawals by simply refusing to propose output roots. For this reason, we believe that this vulnerability only affects permissionless mode OP-Succinct deployments.
Technical analysis
The issue comes from the following check in the client executor (link)
If the starting l2 output root is the same as the ending l2 output root, then the proposer can prove a transition between any l2 blocks. In other words, a range proof of (starting_l2_block_number, starting_l2_root, ending_l2_block_number, starting_l2_root) will incorrectly verify.
Mitigation
This vulnerability can be fixed by removing the shortcut, as in this pr.
Recommendations
If you're running v2.3.0 permissionless mode, switch to permissioned mode.
Upgrade to v3.0.0 when it is audited and released.
Acknowledgements
Thanks to cergyk for finding and disclosing this vulnerability.