search

code-423n4 / 2022-09-artgobblers-findings

0 stars 0 forks source link

Upgraded Q -> M from 269 [1665775697646] #485

Closed code423n4 closed 1 year ago

code423n4 commented 1 year ago

Judge has assessed an item in Issue #269 as Medium risk. The relevant finding follows:

GalloDaSballo commented 1 year ago

[Q-3] Randomness Provider Upgrade Can Be Temporarily Blocked and Delayed

Affected files:

src/ArtGobblers.sol Description: If the owner of the ArtGobblers contract attempts a random provider upgrade an attacker may revert the upgrade transaction and temporarily prevent it from being called for a short "blackout window". This can be achieved by front-running calls to upgradeRandProvider with a call to requestRandomSeed. Exploiting this also requires that the requestRandomSeed cooldown has expired.

The upgrade blackout window can open any time as soon the reveal cooldown expires and lasts from when the new seed is requested until that request is fulfilled. The upgrade blackout window may be extended by an attacker via block stuffing or other attacks against the randomness provider mechanism or even the Ethereum network itself.

This may not be so critical if an upgrade is required because e.g. Chainlink VRF v1 is sunset which would likely come with days if not months of advanced notice. However in a scenario where a critical vulnerability is discovered in the randomness provider it may be much more critical to upgrade it in a timely manner, an added delay of even a couple blocks could allow an attacker to cause substantial additional damage depending on the vulnerability discovered.

Note on severity: Due to the requirement for a particular class of randomness provider vulnerabilities which do not seem to currently exist in Chainlink VRF v1 this issue has been deemed as "low".

Recommendation: Require new randomness always be requested in two steps: 1. inititate seed request 2. request seed. A minimum delay between the two steps should be enforced. This will ensure that as long as the seed request has not been initiated the owner can easily complete a randomness provider upgrade without worrying about race conditions. Note that this is still vulnerable to block stuffing attacks. Alternatively always allow the owner to upgrade the randomness provider regardless of whether an existing request is in progress, this comes at the tradeoff of allowing the owner to intervene in existing requests.

Dup of #153