Open code423n4 opened 3 years ago
Finding is valid, there are cases that can cause a - b to revert
The finding is reliant on external condition (multiplier being low and / or bonding late) as such I believe this to be a medium severity finding.
Note for the sponsor: The cause for reverts should get clearer with time (as people use the protocol), you definitely want to model these revert behaviour to avoid edge cases that will make funds stuck
Handle
WatchPug
Vulnerability details
The
newRatio
that determinestokensNeeded
to settle the auction is calculated based onauctionMultiplier
,bondTimestamp - auctionStart
andauctionDecrement
.However, if an auction is bonded late (
bondTimestamp - auctionStart
is a large number), and/or theauctionMultiplier
is small enough, and/or theauctionDecrement
is small enough, that makesb
to be greater thana
, so thatuint256 newRatio = a - b;
will revert on underflow.This might seem to be an edge case issue, but considering that a rebalance auction of a bag of shitcoin to high-value tokens might just end up being bonded at the last minute, with a
newRatio
near zero. When we take the time between the bonder submits the transaction and it got packed into a block, it's quite possible that the finalbondTimestamp
gets large enough to reveta - b
.Impact
An auction successfully bonded by a regular user won't be able to be settled, and the user will lose the bond.
Proof of Concept
With the configuration of:
basket.ibRatio = 1e18 factory.auctionDecrement = 5760 (Blocks per day) factory.auctionMultiplier = 2
bondForRebalance()
and it will succeed;settleAuction()
will always revert.Recommended Mitigation Steps
Calculate and require
newRatio > 0
inbondForRebalance()
, or limit the max value of decrement and make sure newRatio always > 0 insettleAuction()
.