024.md

RAinUsTa

medium

Adversarial sequencer can censor honest sequencer over P2p

Summary

Note that in the sherlock description, it says: "Moreover, the network should even be robust against batches which could be posted by a malicious sequencer."

This is a MEDIUM vulnerability under the conditions:

1. the single trust-worthy sequencer key is compromised by a malicious actor, OR
2. in the future, the network decentralizes and supports multiple sequencers, and some are adversarial

So, let's assume that there's an adversarial sequencer in the P2P network, and it wants to inflict harm or to censor the other sequencers.

Vulnerability Detail

What this evil sequencer would do is for current and future block height, pre-release blocks (potentially with empty payload or only payload beneficial to the actor) in order to pre-fill the blockHeightLRU cache, and can easily tweak the blocks just slightly so that the block hash is different.

Once the evil sequencer has polluted the seenBlocks data structure for that block height, the honest sequencer who does not pre-release blocks will be ignored by the network.

Note that the evil sequencer can poison the cache up to 5 seconds into the future, so it can always stay one Bedrock block ahead of the honest sequencer.

Impact

A malicious sequencer can force all clients in the network to accept their blocks ahead of an honest sequencer.

This is simply due to the malicious sequencer being able to pre-release blocks slightly earlier than an honest sequencer who only produces block on schedule. Even when the honest sequencer produces a new block, it will be ignored by all clients with error ValidationReject

Code Snippet

See gossip.go https://github.com/sherlock-audit/2023-01-optimism/blob/main/optimism/op-node/p2p/gossip.go#L306-L309

Tool used

Manual Review

Recommendation

blockHeightLRU should not be keyed only on block height, but on (block height, block signer) so that adversarial sequencers cannot censor honest sequencers