The depositTokens
function in the Starklane bridge contract accepts an unsanitized array of token IDs, potentially leading to unbounded loops and out-of-gas issues during execution in _depositIntoEscrow
.
In the depositTokens
function, the ids
parameter is declared as follows:
The function does not impose any limit on the length of the ids
array. This lack of input validation can lead to the following issues:
An attacker could provide an extremely large array of token IDs, causing the loop to consume excessive gas.
If the array is too large, it may exceed the block gas limit, making the transaction impossible to execute.
Even if the transaction doesn't fail outright, it may become prohibitively expensive to execute, effectively DoS-ing the function.
Denial of Service (DoS) attacks on the bridge contract and Excessive gas costs for users attempting legitimate large transfers and also Potential blocking of the entire bridging process if a transaction with too many IDs cannot be processed.
The severity is high due to the potential for DoS attacks and the fundamental disruption to the bridge's core functionality.
Manual code review
Implement a maximum limit for the ids array length:
uint256 constant MAX_IDS_PER_DEPOSIT = 100;
// Adjust this value as appropriate
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
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.