ck - Malicious depositos and relayers can cause denial of service in mintDepositInQueue

[sherlock-admin]

ck

medium

Malicious depositos and relayers can cause denial of service in mintDepositInQueue

Summary

Malicious depositos and relayers can cause denial of service in mintDepositInQueue

Vulnerability Detail

An attacker could prevent other users from having their deposits minted by continually increasing the queue.

The mintDepositInQueue function clears the queue from the tail to the head:

        // queue is executed from the tail to the head
        // get last index of queue
        uint256 i = length - 1;
        while ((length - _operations) <= i) {
            // this loop impelements FILO (first in last out) stack to reduce gas cost and improve code readability
            // changing it to FIFO (first in first out) would require more code changes and would be more expensive
            _mintShares(
                queue[i].receiver,
                _epochId,
                queue[i].assets - relayerFee
            );

The attacker is able to prevent the early deposits in the queue from being cleared by frontrunning relayers with a large number of small deposits.

Ideally, relayers should be able to specify a very high number of operations to clear, but this could fail due to the loop growing too big and running out of gas.

The attacker could themselves be a relayer to reduce the cost of the attack. What they could do is make the deposits they use for the DOS be equal to or slightly larger than the relayer fee. They would then relay some of their deposits therefore getting their funds back and then repeating the process. The attack would be amplified by multiple attackers.

Whereas the DOS could eventually be resolved, it would take concerted effort as the malicious depositors could also be relayers monitoring the mempool and would continue attempting to thwart resolution.

Impact

Denial of service of deposits. The protocol team would constantly have to deal with DOS attempts.

Code Snippet

https://github.com/sherlock-audit/2023-03-Y2K/blob/main/Earthquake/src/v2/Carousel/Carousel.sol#L331-L338

Tool used

Manual Review

Recommendation

The first in last out makes this DOS a likelihood. A first in first out approach may be the better option as it solves the issue.

Duplicate of #174