Open code423n4 opened 1 year ago
Lack of check to guarantee invariant
msclecram marked the issue as sponsor acknowledged
Similarly to #10 and #11, the Warden has shown a way for an invariant to be broken based on configuration.
Because certain aspects of the codebase are using the invariants which can be bypassed as shown above, I agree with Medium Severity
GalloDaSballo marked the issue as selected for report
We updated the code with the next changes: -We removed setPlotsAvailablePerSize
https://github.com/bisonic-official/plot-contract/commit/ea8abd7faffde4218232e22ba5d8402e37d96878
Lines of code
https://github.com/code-423n4/2022-12-forgotten-runiverse/blob/00a247e70de35d7a96d0ce03d66c0206b62e2f65/contracts/RuniverseLandMinter.sol#L513
Vulnerability details
Impact
The function
setPlotsAvailablePerSize
can be used for two things:However, in both cases it can introduce errors that can brick parts of the contract. In case 1 where the number of plots is decreased, it is possible that the new number is smaller than
plotsMinted
for a specific ID. This will cause an underflow ingetAvailableLands
, which subtracts these values:On the other hand, when the number of available plots per size is increased, the minting can fail. This can happen because the
MAX_SUPPLY
inRuniverseLand
is set to 70000, which is also the sum of allplotsAvailablePerSize
entries. When the sum of these entries is increased beyond 70000, some tokens cannot be minted, because theMAX_SUPPLY
is already reached.Proof Of Concept
plotsAvailablePerSize[0]
is changed by the owner to 54500, all other entries are kept the same. Because more users prefer cheap plots, they buy all 54500 plots of size 8x8 and 15500 plots of size 16x16. However, this means that 70000 tokens are minted and no one can buy the 32x32 or 64x64, leading to a substantial financial loss for the protocol (because larger investors might have bought them later, but can no longer do so).Recommended Mitigation Steps
Enforce that
plotsMinted