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.
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:
Retrieving Balances: Calls the borrowBalanceStored
and balanceOf
functions on the respective MErc20Delegator contracts to fetch borrow and token balances for the user.
String Manipulation and Encoding: Converts the address to a string and performs encoding operations for message construction.
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.
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.
Manual code review
To mitigate this DoS vulnerability, the following recommendations are suggested:
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.
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.
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.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.