DeFiFoundry
60,000 USDC
View results
Submission Details
Severity: low
Valid

Delegatecall in a Payable Function Inside a Loop

Summary

The function createTradingAccountAndMulticall utilizes delegatecall inside a loop within a payable function.

Impact

  1. Reentrancy Attacks: Using delegatecall can allow the target function to call back into the calling contract, potentially leading to reentrancy vulnerabilities.

  2. Denial of Service (DoS): A failure in any iteration of the loop can revert the entire transaction, making the function susceptible to DoS attacks.

  3. Gas Limit Issues: Executing delegatecall in a loop can lead to high gas consumption, potentially exceeding the block gas limit and causing transactions to fail.

Tools Used

**Framework **Foundry + Slither

Test Cases:

  1. Gas Limit Test: Ensures that the function does not exceed the gas limit with large input data.

function testGasLimit() public {
bytes[] memory data = new bytes[](1024);
for (uint i = 0; i < data.length; i++) {
data[i] = hex"12345678";
}
bytes memory referralCode = hex"1234567890abcdef";
bool isCustomReferralCode = false;
(bool success, ) = address(tradingAccountBranch).call{value: 1 ether}(abi.encodeWithSignature(
"createTradingAccountAndMulticall(bytes[],bytes,bool)",
data,
referralCode,
isCustomReferralCode
));
assertTrue(success, "should succeed within gas limit");
}

The transaction exceeded the gas limit and failed, indicating a potential vulnerability.

Implications

  • DoS Vulnerability:

    • The function can fail when processing large arrays due to high gas consumption, making it susceptible to Denial of Service (DoS) attacks.

  • Unpredictable Execution:

    • The function might work for smaller arrays but fail for larger ones, leading to unpredictable behavior and potentially failed transactions.

Recommendations

To mitigate the identified risks, consider the following recommendations:

  1. Avoid Delegatecall in Loops:

    • Refactor the code to avoid using delegatecall inside loops. Consider using external contracts for each call if necessary.

  2. Implement Reentrancy Guards:

    • Use the OpenZeppelin ReentrancyGuard modifier to prevent reentrancy attacks.

  3. Handle Failures Gracefully:

    • Instead of reverting on failure, handle the errors gracefully and log the failure events for further inspection.

  4. Batch Processing:

    • Split the processing into multiple transactions to avoid exceeding the gas limit. Implement batch processing to handle large arrays incrementally.

  5. Gas Optimization:

    • Optimize the function to minimize gas usage, and avoid processing large arrays within a single transaction.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Validated
Assigned finding tags:

`createTradingAccountAndMulticall` shouldn't be payable

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.