ethereum-optimism / ethereum-optimism/specs
(Spec) Bug Report: Cyclic Attack Using Interop Message Passing
- Dominant language
- Python
- Stars
- 178
- Forks
- 206
- Avg merge
- 5d 2h
- Merged PRs (30d)
- 6
Description
Looking at the current [interop spec](https://specs.optimism.io/interop/overview.html), I believe there may be a security issue when initiating and executing messages are executed at the same timestamp. If I'm right, the problem arises from logical precedence being lost when messages are passed.
Perhaps this is supposed to be addressed at a higher level of abstraction that I'm not anticipating. Apologies if that's the case - I am but a researchoor.
### Example
Consider two blocks produced at the same timestamp by a malicious sequencer. Block A containing transaction T_a and block B containing transaction T_b.
#### Abstractly the attack runs like this:
* T_b reads an initiating message, m_a, from A which is a prerequisite to it emitting an initiating message, m_b.
* T_a reads m_b from B which is a prerequisite for it emitting m_a.
The transactions would not be valid if executed sequentially, but they are when done on different chains in the superchain.
#### A more concrete attack:
On chain A there is a contract which allows anyone holding an NFT in collection C to mint another NFT in collection C, otherwise they can be bought for 10 Eth. Assume that no NFTs have been minted in the collection yet.
* T_b reads an initiating message, m_a, from A which transfers an NFT in C to the attacker on B.
* T_b emits m_b that transfers the NFT to A.
* T_a reads m_b and uses ownership of the NFT to mint another NFT in C.
* T_a emits m_a which bridges the new NFT to B
T_a is valid since it depends on m_b which is emitted on B and similarly T_b is valid since it depends only on m_a being emitted which it is - i.e. the attacker can bridge an NFT from B to A because it received the NFT via m_a.
Before the attack, the attacker didn't own an NFT and after the attack they do despite them not paying. Without the message passing protocol this wouldn't have been possible even with loans since no NFT existed before.
I realise this specific attack can be defended against at the smart contract level, but I thought I'd raise it since, from my understanding, this is a new problem opened up by synchronous message passing and might apply quite widely.
Contributor guide
Research direction
Start with the linked interop spec overview and trace how initiating and executing messages are ordered when two chains produce blocks at the same timestamp. Reproduce or formally analyze the cyclic dependency described in the example, then determine whether the specification needs clarification or a protocol change; done means the concern has a documented resolution and corresponding spec treatment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- blockchain
- Domain
- blockchain, security
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100