Open code423n4 opened 1 year ago
0xA5DF marked the issue as primary issue
I would expect challenges to last for hours or days and bids to be made near the end of the challenge, so this should not be an issue in practice.
luziusmeisser marked the issue as sponsor acknowledged
hansfriese changed the severity to QA (Quality Assurance)
hansfriese marked the issue as grade-b
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, thelaunchChallenge
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:
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.
Another example, the incident of 4 minutes long reorg back in December.
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 challengeid == X + 1
. Charlie wants to make a bid in an Alices challenge and he calls thebid
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.
Recommended Mitigation Steps
Use a unique identifier of the challenge that doesn't depend on the transaction order. It can be a hash of the
Challenge
structure.