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.
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.
Lines of code
https://github.com/code-423n4/2022-12-forgeries/blob/main/src/VRFNFTRandomDraw.sol#L23-L24
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://docs.chain.link/docs/vrf-security-considerations/#choose-a-safe-block-confirmation-time-which-will-vary-between-blockchains https://github.com/pooltogether/pooltogether-rng-contracts/blob/master/contracts/RNGChainlink.sol https://github.com/pooltogether/v4-core/blob/master/contracts/DrawBeacon.sol#L311-L324 https://github.com/pooltogether/v4-core/blob/master/contracts/DrawBeacon.sol#L218-L232 https://github.com/pooltogether/blockhash-analysis-simulation
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.