An attacker can exploit a vulnerability in the code to perform a Denial of Service (DOS) attack on the protocol. By creating multiple unique addresses and staking 1 wei of TST and EUROs, the attacker can fill up the holders array and consume all the available block gas limit, rendering the protocol non-functional.
When a user stakes TST or EUROs using the LiqidationPool:increasePosition function, their address is added to the holders array using the addUniqueHolder function if the address is new and has not been added before.
The holders array is later used in the distributeAssets function to loop through all the holders and process their positions.
In the distributeAssets function, there is a nested loop that iterates through the holders array twice. The first loop calculates the total staked amount in the getStakeTotal function, and the second loop processes individual stakes.
Looping in Solidity can be inefficient, especially when dealing with unbounded loops, as it can consume all the available block gas limit. A single Ethereum block has a maximum gas limit of 30 million, and if the holders array is large enough, it can easily consume all the gas limit, causing the distributeAssets function to revert.
The audit page mentions that this issue is known, assuming that it would take a long time to fill up the holders array with true stakers. However, an attacker can exploit this vulnerability by creating thousands of unique addresses and staking 1 wei of both TST and EUROs, filling up the entire holders array and causing the protocol to experience a DOS attack.
This vulnerability can lead to the protocol's liquidation and reward distribution being reverted, rendering the protocol non-functional.
manual review
It is recommended to implement a limit on the number of holders in the array to prevent this vulnerability from being exploited.
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.