xiaoming90 - Minter could mint M tokens without any Eligible Collateral

[sherlock-admin4]

xiaoming90

high

Minter could mint M tokens without any Eligible Collateral

Summary

Minters could mint M tokens without any Eligible Collateral. As a result, the on-chain minted M tokens will not be backed by an adequate amount of Eligible Collateral. With fewer Eligible Collateral (e.g., T-Bill) backing the minted M Tokens than expected, the price of M tokens might fall significantly below the \$1 peg, affecting the stability of the protocol.

Vulnerability Detail

Assume that the following state:

• Bob (minter) has \$10M of 30-day T-bills in the Eligible Custody Solution (ECS)
• Update Collateral Interval = 1 day (24 hours)
• Mint Ratio = 80%
• Validator Threshold = 2

Note that after Day 30, the \$10M of the 30-day T-bills will mature and convert to bank deposits, which are not considered Eligible Collateral. This means that on Day 31, if Bob fetches the signatures from the validators and submits them to the gateway, his on-chain collateral balance will be zero, and he will not be able to mint any M tokens.

On Day 31, if Bob does not call the Update Collateral within the update collateral interval (1 day), his on-chain collateral balance will become zero, and he will also be unable to mint any M tokens. In short, the controls are implemented within the protocol to ensure that Bob cannot mint any M tokens on Day 31 in this scenario.

However, Bob can use the following trick or workaround that allows him to continue to mint M tokens even if he no longer has any Eligible Collateral on the ECS on Day 31.

1. On Day 29, fetches the signatures ($Sig_1, Sig_2$) from the validators one hour before the 30-day T-bills mature. The signatures obtained from the validators will state that Bob's Eligible Collateral is \$10M. Keep and do not submit the signatures yet.
2. On Day 31, Bob has zero Eligible Collateral in ECS because all his 30-Day T-bill has matured.
3. Bob decided not to fetch the new signatures from the validators because the signatures would indicate that he has zero Eligible Collateral, which is unfavorable to him. He also cannot mint M tokens without performing a Update Collateral because he has missed an update interval, and his on-chain collateral value is zero now.
4. However, Bob can submit the signatures that he obtained earlier ($Sig_1, Sig_2$) to the updateCollateral function to have his on-chain collateral balance to be restored to \$10M. Since the gateway detected that Bob has updated his collateral at this interval, the protocol will not assume his balance to be zero. As such, he can continue to mint M tokens on Day 31.

The root causes of this issue are as follows:

• The validator's signature does not expire. It will remain valid for hours, days, or even months. As a security best practice, a signature should only be valid for 10 minutes at the maximum. 10 minutes is more than sufficient for the minter to collect the signatures from all the validators to reach the threshold. The expiry length should be set as short as possible yet reasonable for the minters to collect the required number of signatures to be submitted to the gateway.

• The signature does not map to a specific day. Thus, in the above scenario, Bob could use the signature obtained on Day 29 on Day 31.

https://github.com/sherlock-audit/2023-10-mzero/blob/main/protocol/src/MinterGateway.sol#L181

File: MinterGateway.sol
180:         // Verify that enough valid signatures are provided, and get the minimum timestamp across all valid signatures.
181:         minTimestamp_ = _verifyValidatorSignatures(
182:             msg.sender,
183:             collateral_,
184:             retrievalIds_,
185:             metadataHash_,
186:             validators_,
187:             timestamps_,
188:             signatures_
189:         );

Impact

The on-chain minted M tokens will not be backed by an adequate amount of Eligible Collateral. With fewer Eligible Collateral (e.g., T-Bill) backing the minted M Tokens than expected, the price of M tokens might fall significantly below the \$1 peg, affecting the stability of the protocol.

Code Snippet

https://github.com/sherlock-audit/2023-10-mzero/blob/main/protocol/src/MinterGateway.sol#L181

Tool used

Manual Review

Recommendation

Consider adding the expiry and date/day fields to the signature to mitigate the attack mentioned in this report.

  minTimestamp_ = _verifyValidatorSignatures(
      msg.sender,
      collateral_,
      retrievalIds_,
      metadataHash_,
      validators_,
      timestamps_,
+     expiry_,
+     date,
      signatures_
  );

By implementing the above solution, Bob's obtained signatures from the validators will be rendered useless after a short period, and he cannot submit signatures intended for Day 29 on Day 31. Thus, these measures effectively prevent Bob's attack.

[PierrickGT]

Invalid issue.

The scenario described by the watson is incorrect. At step 4, when submitting the signatures (Sig1,Sig2), these signatures will be staled since their minTimestamp will have been stored in _minterStates[minter_].updateTimestamp when updating their collateral and since this timestamp will be dated on Day 29, their collateral on Day 31 will be 0 since they will have missed an update collateral interval. Hence, collateralOf() will return 0 and they won't be able to mint any new M.

Code snippets: https://github.com/MZero-Labs/protocol/blob/f4a13fb3950ff7d10069f4b63d0c2c0a275f6e22/src/MinterGateway.sol?plain=1#L539 https://github.com/MZero-Labs/protocol/blob/f4a13fb3950ff7d10069f4b63d0c2c0a275f6e22/src/MinterGateway.sol?plain=1#L574

[sherlock-admin2]

1 comment(s) were left on this issue during the judging contest.

takarez commented:

i think this is theoretically not possible given the fact that the minters are themselves trusted(as per sponsor) and also the validator has the responibility to oversee the minter's action and there also a time diff between the execution of it.