Open sherlock-admin3 opened 5 months ago
1 comment(s) were left on this issue during the judging contest.
takarez commented:
6000 signatures will definately ring a bell for the validator to check for malicious activity; remember the validator atest to the eligible collatreal.
While a valid finding, it would require validators and governance to really be sleeping at the wheel and/or behaving on reckless autopilot.
We should probably fix it by preventing the update collateral from penalizing the minter more than once per missed update.
However, consider than by attempting to do this, the Minter is losing all their off-chain collateral and being deactivated, and the reckless validators will likely lose their validator gig.
Valid issue, medium severity, great catch đź‘Ť
I think this not valid because we need signature and new timestamp for every update and that is impossible
The protocol team fixed this issue in the following PRs/commits: https://github.com/MZero-Labs/protocol/pull/173
The Lead Senior Watson signed off on the fix.
pkqs90
high
Malicious minters can repeatedly penalize their undercollateralized accounts in a short peroid of time, which can result in disfunctioning of critical protocol functions, such as
mintM
.Summary
Malicious minters can exploit the
updateCollateral()
function to repeatedly penalize their undercollateralized accounts in a short peroid of time. This can make theprincipalOfTotalActiveOwedM
to reachuint112.max
limit, disfunctioning some critical functions, such asmintM
.Vulnerability Detail
The
updateCollateral()
function allows minters to update their collateral status to the protocol, with penalties imposed in two scenarios:The critical issue arises with the penalty for being undercollateralized, which is imposed on each call to
updateCollateral()
. This penalty is compounded, calculated aspenaltyRate * (principalOfActiveOwedM_ - principalOfMaxAllowedActiveOwedM_)
, and theprincipalOfActiveOwedM_
increases with each imposed penalty.Given that validator provides timely information about the off-chain collateral (according to https://docs.m0.org/portal/overview/glossary#validator), a minter could potentially gather validator signatures with high frequency (for example, every minute). With a sufficient collection of signatures, a malicious minter could launch an attack in a very short timeframe, not giving validators time to deactivate the minter.
Proof Of Concept
We can do a simple calculation, using the numbers from unit tests, mintRatio=90%, penaltyRate=1%, updateCollateralInterval=2000 (seconds). A malicious minter deposits
$100,000
t-bills as collateral, and mints$90,000
M tokens. Since M tokens have 6 decimals, the collateral would be100000e6
. Following the steps below, the malicious minter would be able to increaseprincipalOfActiveOwedM_
close to uint112.max limit:updateCollateral()
. The penalty for missing updates would be4 * 90000e6 * 1% = 36e8
.36e8
, we can keep callingupdateCollateral()
to compound penalty for undercollateralization. Each time would increase the penalty by 1%. We only needlog(2^112 / 36e8, 1.01) ~ 5590
times to hituint112.max
limit.Add the following testing code to
MinterGateway.t.sol
. We can see in logs thatprincipalOfTotalActiveOwedM
has hit uint112.max limit.Note that in real use case, the penalty rate may lower (e.g. 0.1%), however,
log(2^112 / 36e8, 1.001) ~ 55656
is still a reasonable amount since there are 1440 minutes in 1 day (not to mention if the frequency for signature may be higher than once per minute). A malicious minter can still gather enough signatures for the attack.Impact
The direct impact is that
principalOfTotalActiveOwedM
will hituint112.max
limit. All related protocol features would be disfunctioned, the most important one beingmintM
, since the function would revert ifprincipalOfTotalActiveOwedM
hits uint112.max limit.Code Snippet
Tool used
Foundary
Recommendation
Consider only imposing penalty for undercollateralization for each update interval.