Interchain token transfer can be Dossed Due To Flow Limit

[code423n4]

Lines of code

https://github.com/code-423n4/2023-07-axelar/blob/2f9b234bb8222d5fbe934beafede56bfb4522641/contracts/its/token-manager/TokenManager.sol#L83-L173
https://github.com/code-423n4/2023-07-axelar/blob/2f9b234bb8222d5fbe934beafede56bfb4522641/contracts/its/interchain-token/InterchainToken.sol#L1-L106

Vulnerability details

Impact

A large token holder can send back and forth tokens, using the flow limit to the capacity in start of every epoch making the system unusable for everyone else.

Proof of Concept

Interchain tokens can be transferred from one chain to another via the token manager and interchain token service.

And there is a limit imposed, for both the flow out and flow in.

Flow out happens when we send the token from one chain to another. Lets say arbitrum to optimism and we are sending USDC. So in this case, in context of arbitrum it will be flow out and in context of optimism it will be flow in and and receiver on optimism will get the tokens via the token manager 'giveToken()' callable by the inter chain token service.

But there is a flow limit impose per epoch.

One Epoch = 6 hours long.

So there cannot be more than certain amount of tokens sent between the chain per 6 hours. This is done to protect from the uncertain conditions like a security breach and to secure as much of tokens as possible.

But the problem with such design is big token holder or whale could easily exploit it to DOS the other users.

Consider the following scenerio:

1. Epoch starts.
2. Limit imposed for the flow is 10 million USDC (considering usdc to be interchain token for ease of understanding).
3. A big whale transfer 10 million USDC in start of the epoch and those are there and may or may not receive them on other end right away.
4. But the limit have been reached for the specific epoch. Now no other user can use the axelar interchain token service to transfer that particular token on the Dossed lane.
5. Now attacker can repeat the process across multiple lanes on multiple chain or one, in start of every epoch making it unusable for every one with very minimum cost.

This attack is pretty simple and easy to acheive and also very cheap to do, specifically on the L2's or other cheap chains due to low gas price.

Function using the flow limit utility in tokenManager.sol are following

    function sendToken(
        string calldata destinationChain,
        bytes calldata destinationAddress,
        uint256 amount,
        bytes calldata metadata
    ) external payable virtual {
        address sender = msg.sender;
        amount = _takeToken(sender, amount);
        _addFlowOut(amount);
        interchainTokenService.transmitSendToken{ value: msg.value }(
            _getTokenId(),
            sender,
            destinationChain,
            destinationAddress,
            amount,
            metadata
        );
    }

    /**
     * @notice Calls the service to initiate the a cross-chain transfer with data after taking the appropriate amount of tokens from the user.
     * @param destinationChain the name of the chain to send tokens to.
     * @param destinationAddress the address of the user to send tokens to.
     * @param amount the amount of tokens to take from msg.sender.
     * @param data the data to pass to the destination contract.
     */
    function callContractWithInterchainToken(
        string calldata destinationChain,
        bytes calldata destinationAddress,
        uint256 amount,
        bytes calldata data
    ) external payable virtual {
        address sender = msg.sender;
        amount = _takeToken(sender, amount);
        _addFlowOut(amount);
        uint32 version = 0;
        interchainTokenService.transmitSendToken{ value: msg.value }(
            _getTokenId(),
            sender,
            destinationChain,
            destinationAddress,
            amount,
            abi.encodePacked(version, data)
        );
    }

    /**
     * @notice Calls the service to initiate the a cross-chain transfer after taking the appropriate amount of tokens from the user. This can only be called by the token itself.
     * @param sender the address of the user paying for the cross chain transfer.
     * @param destinationChain the name of the chain to send tokens to.
     * @param destinationAddress the address of the user to send tokens to.
     * @param amount the amount of tokens to take from msg.sender.
     */
    function transmitInterchainTransfer(
        address sender,
        string calldata destinationChain,
        bytes calldata destinationAddress,
        uint256 amount,
        bytes calldata metadata
    ) external payable virtual onlyToken {
        amount = _takeToken(sender, amount);
        _addFlowOut(amount);
        interchainTokenService.transmitSendToken{ value: msg.value }(
            _getTokenId(),
            sender,
            destinationChain,
            destinationAddress,
            amount,
            metadata
        );
    }

    /**
     * @notice This function gives token to a specified address. Can only be called by the service.
     * @param destinationAddress the address to give tokens to.
     * @param amount the amount of token to give.
     * @return the amount of token actually given, which will onle be differen than `amount` in cases where the token takes some on-transfer fee.
     */
    function giveToken(address destinationAddress, uint256 amount) external onlyService returns (uint256) {
        amount = _giveToken(destinationAddress, amount);
        _addFlowIn(amount);
        return amount;
    }

    /**
     * @notice This function sets the flow limit for this TokenManager. Can only be called by the operator.
     * @param flowLimit the maximum difference between the tokens flowing in and/or out at any given interval of time (6h)
     */
    function setFlowLimit(uint256 flowLimit) external onlyOperator {
        _setFlowLimit(flowLimit);
    }

Tools Used

Manual review

Recommended Mitigation Steps

There could be many solution for this one. But two solutions from top of my head are:

1. Do the chainlink way CCIP way, chainlink recently launched cross chain service solved the similar problem by imposing the token bps fee, by imposing such fee along with gas fee, cost of attack becomes way higher and system can be protected from such attack.

2. Introduce the mechanism of limit per account, instead of whole limit. But that can be exploited too by doing it through multiple accounts.

Chainlink's way would be the better solution to go with IMO.

Assessed type

DoS

[c4-pre-sort]

0xSorryNotSorry marked the issue as primary issue

[c4-sponsor]

deanamiel marked the issue as disagree with severity

[deanamiel]

Corrected Severity: QA
This behavior is intentional. If an attacker tries to block one way (either in or out), the operator can respond by increasing the flowLimit (or setting it to 0 meaning there's no limit at all) to help handle the attack. We prefer to keep fees as low as possible, so we would not want to use the Chainlink method that was suggested.

[berndartmueller]

Even though this is intentional, the demonstrated issue can cause temporary availability (inability to transfer tokens) issues for the token service. This qualifies for medium severity, according to the C4 judging criteria:

Assets not at direct risk, but the function of the protocol or its availability could be impacted,

[c4-judge]

berndartmueller changed the severity to 2 (Med Risk)

[c4-judge]

berndartmueller marked the issue as selected for report

[milapsheth]

We consider this QA for the following reasons:

1. Rate limits are intended to reduce availability/liveness on large transfers, so liveness concern by itself isn't applicable to judge this issue.
2. Rate limits are opt-in and updatable, operators are recommended to choose the parameters carefully to determine the risk/liveness trade-off, and take operational responsibility to maintain it.
3. The design is intentional. We consider other proposed designs to have worse trade-offs. A bps fee introduces a fee-on-transfer behaviour, and a high cost to otherwise honest large transfers. Per account limits are not Sybil resistant. We're happy to consider other designs if they're better, but the report doesn't cover that.