Closed code423n4 closed 11 months ago
0xSorryNotSorry marked the issue as primary issue
guardians are trusted, non issue
ElliotFriedman marked the issue as sponsor disputed
The damage is minimal, and the obvious mitigation of replacing the malicious guardians obvious. Not even worth it to add in the docs.
alcueca marked the issue as unsatisfactory: Overinflated severity
Lines of code
https://github.com/code-423n4/2023-07-moonwell/blob/fced18035107a345c31c9a9497d0da09105df4df/src/core/Comptroller.sol#L844 https://github.com/code-423n4/2023-07-moonwell/blob/fced18035107a345c31c9a9497d0da09105df4df/src/core/Comptroller.sol#L807
Vulnerability details
Impact
An admin or cap guardian are able to set their caps to any arbitrary value without any timelock or restrictions. This can be abused by a malicious admin or guardian to prevent certain users from joining (or borrowing from) particular markets using frontrunning.
I believe medium severity is suitable as it can prevent users from being able to use the protocol but assumes we have a malicious guardian or admin
Proof of Concept
Comptroller.sol
through_setSupplyCapGuardian()
mDAI.mint()
supplyCap
to1
mDai.mint()
will callcomptroller.mintAllowed()
to ensure that all checks pass. However, assupplyCap != 0
, unless there is no available funding inmDAI
, then themintAmount + cash + borrows - reserves < totalSupplyCap
will fail thereby preventing Bob from joining the marketTools Used
VSCode
Recommended Mitigation Steps
Consider adding a timelock to the supply caps with a queue and execute system or adding a minimum value (i.e. the current supply of the market) so that certain users cannot be hazed.
Assessed type
DoS