search

code-423n4 / 2022-11-size-findings

1 stars 0 forks source link

Front-running of `bid` calls #334

Closed code423n4 closed 1 year ago

code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2022-11-size/blob/main/src/SizeSealed.sol#L55 https://github.com/code-423n4/2022-11-size/blob/main/src/SizeSealed.sol#L84 https://github.com/code-423n4/2022-11-size/blob/main/src/SizeSealed.sol#L122

Vulnerability details

Description

There is bid function in the SizeSealed contract. The function accepts the auctionId, which does not contain any information about the auction itself. As a result, transactions of users can be front-runned to enforce them bid for the auction with the same auctionId they doesn't expect to use.

PoC

Someone (lets call him Bob) sends a createAuction transaction to the mempool. After that someone else (lets call him Charlie) sends a transaction bid with auctionId equals to the expected id of the auction. Then the malicious user can send a transaction with higher fee that creates an auction which have the same auctionId but a different content. This transaction most likely will be included in the block before the transaction from Bob so Charlie will use the auction he doesn't expect to use.

So, it is possible that the order of transactions will be the following:

Note, that it is not necessarily for Charlie to send bid transaction to mempool when Bob's createAuction transaction is not included into block to get under attack. That also can happen while chain reorg.

Recommended Mitigation Steps

Use a hash of content as a unique identifier. Then it would be impossible to manipulate or front-run transactions.

trust1995 commented 1 year ago

I think this is a strictly theoretical issue, since it requires users to send a bid to an auctionID that does not exist, based off it's existence in the mempool.

0xean commented 1 year ago

front running someone trying to front run the creation of the auction with an early bid... don't think so

c4-judge commented 1 year ago

0xean marked the issue as unsatisfactory: Insufficient quality

vladbochok commented 1 year ago

@trust1995 @0xean @RagePit I know It is too late to complain. But let me explain my point to make sure you judge on similar issues.

That also can happen while chain reorg.

Yes, the front-run opportunity may be too unrealistic, as it relies on user misbehavior. But what about chain reorg?

The chain reorg frequency depends on the consensus for the L1 blockchain and both the validity mechanism for L2 blocks and its L1 consensus (if L1 blockchain reorgs happen, L2 block reorgs may happen on top of it).

While the Ethereum network doesn't have long reorgs, popular scaling solutions may have:

Here you may be convinced that the Polygon has in practice subject to reorgs. Even more, the reorg on the picture is 1.5 minutes long. So, it is quite enough to create the action and make a bid, especially when someone uses a script, and not doing it by hand.

Optimistic rollups are also suspect to reorgs since if someone finds a fraud the blocks will be reverted, even though the user receives a confirmation and already created a bid.

I don't know if there are any plans on deploying to L2s or Polygon, but if yes, I see the possibility of an attack.