Lines of code

Vulnerability details

Impact

Miners are able to rewrite a chain’s history if they dislike the VRF output used by the protocol. Consider the following example:

A miner or well-funded user is participating in the PoolTogether protocol.
A VRF request is made and fulfilled in the same block.
The protocol participant does not benefit from the VRF output and therefore wants to increase their chances of winning by including the output in another block, producing an entirely new VRF output. This is done by re-orging the chain, i.e. following a new canonical chain where the VRF output has not been included in a block.
This attack can be continued as long as the attacker controls 51% of the network. The miner itself could control a much smaller proportion of the network and still be able to mine a few blocks in succession, although this is of low probability but entirely possible.
A well-funded user could also pay miners to re-org the chain on their behalf in the form of MEV to achieve the same benefit.
The PoolTogether team is aware of this issue but is yet to mitigate this attack vector fully.

#Proof of Concept
<https://github.com/pooltogether/pooltogether-rng-contracts/blob/master/contracts/RNGChainlink.sol&gt;
<https://github.com/pooltogether/v4-core/blob/master/contracts/DrawBeacon.sol#L311-L324&gt;
<https://github.com/pooltogether/v4-core/blob/master/contracts/DrawBeacon.sol#L218-L232&gt;
<https://github.com/pooltogether/blockhash-analysis-simulation&gt;

Tools Used

Manual code review

Recommended Mitigation Steps

Consider adding a confirmation time between when the actual VRF request was made and when it was later fulfilled on-chain. This could be as few as 5 blocks, reducing the probability of an effective chain reorganization to extremely close to 0.

The text was updated successfully, but these errors were encountered:

😕 1 hansfriese reacted with confused emoji

All reactions

• 😕 1 reaction