Bad source of randomness #427
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
primary issue
Highest quality submission among a set of duplicates
responded
The Holograph team has reviewed and responded
selected for report
This submission will be included/highlighted in the audit report
sponsor confirmed
Sponsor agrees this is a problem and intends to fix it (OK to use w/ "disagree with severity")
Lines of code
https://github.com/code-423n4/2022-10-holograph/blob/f8c2eae866280a1acfdc8a8352401ed031be1373/contracts/HolographOperator.sol#L491-L511
Vulnerability details
Impact
Using block.number and block.timestamp as a source of randomness is commonly advised against, as the outcome can be manipulated by calling contracts. In this case a compromised layer-zero-endpoint would be able to retry the selection of the primary operator until the result is favorable to the malicious actor.
Proof of Concept
An attack path for rerolling the result of bad randomness might look roughly like this:
The attack basically consists of repeatedly calling the
attack
function with data that is known and output that is wished for until the results match and only then continuing to calling the operator.Tools Used
Manual Review
Recommended Mitigation Steps
Consider using a decentralized oracle for the generation of random numbers, such as Chainlinks VRF.
It should be noted, that in this case there is a prerequirement of the layer-zero endpoint being compromised, which confines the risk quite a bit, so using a normally unrecommended source of randomness could be acceptable here, considering the tradeoffs of integrating a decentralized oracle.
The text was updated successfully, but these errors were encountered: