Moonwell

Summary

This audit report identifies a DoS vulnerability in the provided MIP-M17 Governor contract. The vulnerability exists within the _build function and can be exploited by an attacker submitting a proposal with excessively large debtor arrays for mFRAX and mxcDOT tokens. Processing such a proposal can consume significant gas, potentially disrupting governance processes and impacting validator efficiency.

Vulnerability Details

The _build function iterates through two user-supplied arrays: mFRAXDebtors and mxcDOTDebtors. These arrays contain a list of addresses for users with potential bad debt. The loop performs the following actions for each address:

1. Retrieving Balances: Calls the borrowBalanceStored and balanceOf functions on the respective MErc20Delegator contracts to fetch borrow and token balances for the user.

2. String Manipulation and Encoding: Converts the address to a string and performs encoding operations for message construction.

3. Action Pushing: Pushes an action to the queue for execution. This action involves calling a function on the MErc20Delegator contract to potentially fix the user's debt.

Each iteration of the loop consumes gas for the operations mentioned above. If either mFRAXDebtors or mxcDOTDebtors contains a very large number of addresses, the total gas cost for processing the proposal can become extremely high.

Impact

This DoS vulnerability can have the following negative impacts:

• High Gas Costs: Even if the proposal doesn't get executed, processing it during voting can lead to high gas costs for validators, potentially slowing down the network and impacting block processing times.

• Failed Transactions: If the gas cost for processing the proposal exceeds the gas limit, the transaction might fail, wasting gas for the attacker but also potentially disrupting governance processes by preventing legitimate proposals from being executed.

Tools Used

• Manual code review

Recommendations

To mitigate this DoS vulnerability, the following recommendations are suggested:

1. Limit Array Size: Implement a maximum size limit for the mFRAXDebtors and mxcDOTDebtors arrays. This prevents attackers from submitting proposals with an unreasonable number of addresses.

2. Gas Optimization: Explore ways to optimize the operations within the loop. This could involve:

   • Batching balance retrievals for multiple addresses instead of calling them individually.

   • Utilizing off-chain processing for initial data validation to reduce on-chain gas consumption.

3. Consider Pagination: If large debtor lists are unavoidable, consider implementing pagination or chunking mechanisms. This would involve processing the debtor list in smaller batches to limit gas consumption per transaction.