安全披露:Optimism 欺诈证明系统中的安全漏洞
Ed Felten, Offchain Labs Co-founder, Source: Medium, Translation: Shan Ou Ba, 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 deployed on their testnet. We provided the OP Labs team with demonstration exploit code. On March 25, OP Labs confirmed the validity of these two issues.
We coordinated our disclosure with the OP Labs team. OP Labs asked us to postpone the public disclosure of these vulnerabilities until they were addressed. Late last night (April 25), the Optimism testnet was updated, and today we publicly disclosed these vulnerabilities for the first time.
These vulnerabilities allow malicious parties to force the OP Stack fraud proof mechanism to accept fraudulent chain history records or prevent the OP Stack fraud proof mechanism from accepting the correct chain history records. These issues stem from flaws in the OP fraud prevention design in handling timers.
The result is that, compared to approaches entirely dependent on emergency intervention by the Security Council, the anti-fraud system did not improve security.
Nature of the Vulnerabilities
Timers are one of the most subtle aspects of interactive fraud prevention design. Opponents may not take any action in the challenge game at all, so at some point, the protocol needs to declare that a player who has not moved has failed due to timeout. But adversaries can also use review attacks on the parent L1 chain (such as Ethereum) to prevent honest parties from participating in the game.
If time passes and a player does not move, the protocol cannot determine whether the player is under review or is a bad actor who remains silent and pretends to be under review. (In both cases, the protocol can only see the player's "radio silence.") Therefore, the protocol must give honest players enough leeway so that they do not fail due to review, while preventing malicious players from delaying the protocol for too long.
For example, in a one-on-one challenge protocol where both disputing parties have one player, the method used by Arbitrum currently deployed in the protocol works very well. Here is an intuitive way to understand this method: each player receives "time points" when it is the other player's turn to move, and if a player accumulates 7 days' worth of time points, they win the challenge due to time. The idea is that if a player is "late" a total of 7 days, such delay is entirely unreasonable due to the review system, so that player can be considered dishonest and can then safely be declared the loser. This allows one-on-one protocols to be safe from reviews up to 7 days long.
This method is very effective when the disputing parties each have one player. However, when you allow many players to participate, as Optimism does, managing time points is not as straightforward. People are easily divided into teams, each disputing party having a team, each with time points. But you need to be careful because of traitorous attacks, where one malicious party pretends to be honest for a period of time and then stabs the honest "teammate" in the back at the worst moment.
The OP protocol originally deployed on the testnet was vulnerable to such traitorous attacks because it allowed traitors to receive undeserved time rewards. This would enable a malicious actor to win a fraud proof game they should lose, thereby accepting a fraudulent chain history or rejecting the correct chain history.
These are difficult-to-solve issues, and while OP's original design was subject to subtle attacks, they made some changes to their timer handling code to address the demonstration vulnerabilities we provided. At present, we have not conducted a security analysis of their protocol after the modifications.
Addressing Timers, Traitors, and Other Attacks
Fraud prevention protocols, especially in 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 evidence that the BoLD protocol is not susceptible to such traitorous attacks. Given the complexity and subtlety of these issues, we believe there must be a clear threat model and security proof to ensure there are no potential attacks. In fact, in the process of creating the proof, we found and fixed multiple issues in the BoLD protocol.
Original Security Disclosure
Here is an extended excerpt of the disclosure we sent to OP Labs on March 22:
We (Offchain Labs team) have identified serious system flaws in the current version of the OP Stack fault proof system. This document describes these flaws and provides example vulnerability code for your reference.
These flaws would allow adversaries to undermine the security and liveliness of the chain by making the protocol accept fraudulent claims, reject correct claims, or create disputes that cannot be resolved within L1 Gas limits. [Note (April 26): The third issue (unresolvable disputes) has been publicly disclosed and documented, so we will remove further mentions.]
<
注册有任何问题请添加 微信:MVIP619 拉你进入群
打开微信扫一扫
添加客服
进入交流群
1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。