code423n4 commented 1 year ago

Lines of code

https://github.com/code-423n4/2023-04-frankencoin/blob/main/contracts/MintingHub.sol#L140 https://github.com/code-423n4/2023-04-frankencoin/blob/main/contracts/MintingHub.sol#L156 https://github.com/code-423n4/2023-04-frankencoin/blob/main/contracts/MintingHub.sol#L199

Vulnerability details

Description

The launchChallenge function creates a challenge and returns its id. The id is determined by a number of already created challenges. In other words, the launchChallenge return consecutive values.

Later user could interact with a challenge by bid,splitChallenge/end functions, all interactions are made by the challenge id.

At the same time, block reorg may happen on any blockchain. A very clear example to consider would be Polygon:

https://polygonscan.com/blocks_forked

Please note, reorg on Polygon happens really often. Some are 1 block long, some are >5 minutes long. For the latest, it is quite enough to call one or two functions, especially when someone uses a script, and not doing it by hand.

Example, the Polygon had an incident of 5.5 minutes long reorg 2 weeks ago.

https://polygonscan.com/block/39599624/f?hash=0x0b7e6c5e9fbae3e2dbd114e4836b52ffb1211820bf62bbbd3ddf859dd07c0fe1

Another example, the incident of 4 minutes long reorg back in December.

https://polygonscan.com/block/36757444/f?hash=0xf9aefee3ea0e4fc5f67aac48cb6e25912158ce9dca9ec6c99259d937433d6df8

While Ethereum seems to be stable, there is no guarantee of the absence of reorgs, which happened a lot previously.

Another interesting impact of this is Optimistic rollups that are quite popular nowadays. Network operators can include a transaction in a block, the user receives the block confirmation and makes a transaction, but the operator reorganizes the blocks for the sake of profit (or because of any other reason, like a bug in server implementation).

Users usually don't have a full node of optimistic rollup to validate whether the state can't be reverted, the same as a user doesn't wait 7 days between submitting transactions.

All in all, the block reorg is expected behavior for the blockchain and should handle properly to avoid loss of user funds.

Attack scenario

Imagine that Alice creates a challenge and receives her challenge id == X. Bob creates a challenge and receives his challenge id == X + 1. Charlie wants to make a bid in an Alices challenge and he calls the bid function with proper _challengeNumber == X.

The network block reorg happens and after it, the order of Alice and Bob's transaction was changed. Thus, Charlie made a bid on Bob's challenge, but he expected to make a bid on Alice's challenge.

Impact

Any significant reorg incident creates a possibility of incorrect challenge bid-making. Also, the use of a small number of confirmations in user transactions can lead to a loss of money.

All in all, it could to the loss of funds under some realistic blockchain state.