code423n4 commented 2 years ago

Handle

leastwood

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 Discussions with Brendan

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.

asselstine commented 2 years ago

Yes, this is something I've known for awhile. The VRF operator whose signature we are requesting could collude with a miner to manipulate the blockhash that is being fed to the VRF.

We're using the original VRF implementation by Chainlink. VRF 2.0 is rolling out soon, and we'll explore confirmation times with their team.

GalloDaSballo commented 2 years ago

The warden has identified a "supply chain" attack on the VRF, while the finding may seem innocuous, it does pose the fundamental question as to whether Chainlink's VRF is a source of truly verifiable randomness that won't be gamed for personal gains.

The sponsor does agree on the attack vector, the miner and the chainlink provider could collude with the purpose of gaming the system.

I find it hard to leave this as a High Severity finding, because it implies that Chainlink's VRF Service is flawed in it's design

However, if trace of proof of collusion between miners and chainlink operators where to be found, this would question the impartiality of their service.

GalloDaSballo commented 2 years ago

After a day of thinking I've decided to leave the finding as high risk. Not as a statement to Chainlink's security model, as that's outside of scope, but because the finding is objectively true.

A malicious operator can, in conjunction with a miner, re-roll the VRF to pursue their own gains.

I'm not sure what could be done to mitigate this at the chain level, it seems to me that at this time, there may be no source of true randomness that can be achieved on-chain without assuming a degree of counter-party risk

code-423n4 / 2021-10-pooltogether-findings