Canto Liquidity Mining Protocol - pep7siup's results

Lines of code

https://github.com/code-423n4/2023-10-canto/tree/main/canto_ambient/contracts/mixins/LiquidityMining.sol#L193 https://github.com/code-423n4/2023-10-canto/tree/main/canto_ambient/contracts/mixins/LiquidityMining.sol#L286

Vulnerability details

Impact

The impact of this vulnerability is significant, as it can result in the loss of rewards for users who control owner contracts. If the owner input for the claimAmbientRewards and claimConcentratedRewards functions corresponds to a contract, it is possible that the owner contract does not, intentionally or unintentionally, implement the receive or fallback function in a way that supports receiving CANTO (the native token) or that calling the owner contract's receive or fallback function executes complicated logics that consume a substantial amount of gas. This could cause the call to claimAmbientRewards or claimConcentratedRewards to revert.

For example, if calling claimAmbientRewards reverts due to issues in the owner contract, the owner contract would not be able to receive their eligible mining rewards. Consequently, the owner contract loses out on the rewards they rightfully deserve, which is unfair to the users who control it.

Proof of Concept

The root cause of the vulnerability is that the claimAmbientRewards and claimConcentratedRewards functions do not handle the scenario where the owner input corresponds to a contract that is unable to receive CANTO through its receive or fallback function. Let's walk through the issue with the following scenario:

1. Alice controls an owner contract that is designed to interact with the CrocSwapDex protocol.

2. Alice's owner contract does not implement the receive or fallback function properly to handle CANTO transfers.

3. Alice decides to call the claimAmbientRewards function to claim her mining rewards from the Prime protocol.

4. The claimAmbientRewards function attempts to transfer CANTO rewards to Alice's owner contract via the low-level owner.call. Due to the improper implementation of the receive or fallback function in Alice's owner contract (OOG or lacking fallback/receive function), the transfer of CANTO reverts.

// File: canto_ambient/contracts/mixins/LiquidityMining.sol
256:    function claimAmbientRewards(
        ...
285:        if (rewardsToSend > 0) {
286:            (bool sent, ) = owner.call{value: rewardsToSend}(""); // <= FOUND: will revert if owner is a contract that is unable to receive CANTO through its receive or fallback
287:            require(sent, "Sending rewards failed");
288:        }
289:    }

5. Alice's owner contract does not receive the mining rewards it is eligible for, resulting in a loss of value for Alice and unfairness in the distribution of rewards.

Tools Used

Manual Review

Recommended Mitigation Steps

To mitigate this vulnerability, it is recommended to enhance the claimAmbientRewards and claimConcentratedRewards functions to handle cases where the owner input corresponds to a contract that may have limitations in receiving CANTO through its receive or fallback function. One possible approach is to use Wrapped CANTO (WCANTO) as an intermediary token to deposit the corresponding CANTO amount when calling these functions. The deposited WCANTO amount can then be transferred to the receiver contract, ensuring that rewards are not lost due to reverts. Another approach could be introducing additional recipient input as a dedicated address from the owner to receive the CANTO rewards on their behalf.

Assessed type

call/delegatecall