Open c4-submissions opened 1 year ago
raymondfam marked the issue as primary issue
raymondfam marked the issue as sufficient quality report
_amountToSell is indeed very close to 100 times (99% plus).
raymondfam marked the issue as high quality report
pi0neerpat (sponsor) confirmed
MiloTruck marked the issue as selected for report
MiloTruck marked the issue as satisfactory
The warden has demonstrated how due to the incorrect use of ONE_HUNDRED_WAD
instead of WAD
when calculating percentages, surplus auctions will be created with massively inflated values, breaking the accounting of the protocol. As such, I agree with high severity.
Selected this report for best as it outlines the issues, impacts and recommended mitigation really well despite the lack of a coded PoC.
Lines of code
https://github.com/open-dollar/od-contracts/blob/dev/src/contracts/AccountingEngine.sol#L198-L236
Vulnerability details
There are two big issues in
AccountingEngine.sol::auctionSurplus()
when calculating values for the creating a Surplus Auction; specifically in Lines 213 - 217.The first issue is the
if
statement at line 213 which incorrectly checks if_params.surplusTransferPercentage
is less thanONE_HUNDRED_WAD
when it should check if it is less thanWAD
.The maximum value for
_params.surplusTransferPercentage
, as checked by the function at line 199, is1e18
so the check at line 213 will always returnTRUE
. However, the check should returnFALSE
when_params.surplusTransferPercentage
is1e18
or100%
because in that case an auction shouldn't be created; rather the fullsurplusAmount
should be transferred toextraSurplusReceiver
in the next code block.The second issue is the use of
ONE_HUNDRED_WAD
to calculate_amountToSell
at Line 215 which results in a hugely inflated figure in the newly created surplus auction. The use ofONE_HUNDRED_WAD
causes the calculated figure to be100 times
greater than it should be.Impact
Issue 1. For the first issue; when
_params.surplusTransferPercentage
is100%
, a ghost surplus Auction will be created and the entiresurplusAmount
amount will also be sent to theextraSurplusReceiver
essentially double-counting a large amount of the surplus. This double accounting can destabilise the system and lead to underflows elsewhere.Issue 2. Surplus auctions are created with massively inflated figures for
_amountToSell
. This has the potential to cause massive price imbalances and crash the protocol. There is potential here for a malicious actor to leverage the vulnerability to their advantage by creating lots of false surplus in system coins which they purchase cheaply.Proof of Concept
The following combines both issues into one PoC to show the worst case scenario. Given the following values and assuming the initial all checks pass in function before reaching [Line 213][M1 Snippet]
AccountingEngine.sol::auctionSurplus()
:The following condition at [Line 213][M1 Snippet] will always return TRUE:
So an auction will be created with
_amountToSell
100 times higher than it should be:Following this, a coin amount of
surplusAmount
is also sent to theextraSurplusReceiver
calculated in Lines 224-231 which is actually the intended behaviour.Tools Used
Manual Review Foundry
Recommended Mitigation Steps
Update the function on the two affected lines to use
WAD
instead ofONE_HUNDRED_WAD
as:Assessed type
Error