Summary

The MIP-M17 contract currently lacks a two-step process for updating critical protocol addresses, including addresses for mErc20DelegateFixer, mErc20DelegateMadFixer, and various token-related operations. This omission can lead to security risks, such as rapid and potentially unauthorized changes to critical contract functionalities without adequate oversight or validation.

Vulnerability Details

The contract defines methods to set and update addresses for key functionalities specifically _setImplementation calls within _build function. However, these updates are directly applied without an interim approval step. This approach could enable an attacker with governance control (or an insider threat) to quickly make changes that could compromise the contract's integrity or user funds.

For instance, the contract sets new implementations for MErc20Delegate for various tokens using:

Impact

Without a two-step process (proposal and confirmation), the system is vulnerable to rapid, non-validated changes to critical components. This vulnerability could be exploited to divert funds, disrupt the contract's functionality, or compromise the system's integrity in various ways.

Tools Used

Manual Review

Recommendations

Implement a two-step procedure for all critical protocol address updates and parameter changes. This procedure should include:

1. Proposal Stage: A governance proposal is submitted for any critical address or parameter change. This proposal should be visible to all stakeholders and include a clear description of the changes and their implications.

2. Confirmation Stage: After a predefined delay (e.g., 48 hours), during which stakeholders can review the proposal and raise concerns, a second transaction is required to confirm and execute the changes. This delay allows for community oversight and, if necessary, veto actions against potentially harmful updates.