Funds will be stuck if the USDC contract blacklists the destination

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-09-centrifuge/blob/main/src/UserEscrow.sol#L15

Vulnerability details

Impact

If the USDC contract were to blacklist the predefined destination address, funds stored in the UserEscrow contract would become permanently locked, rendering them inaccessible.

Proof of Concept

    function transferOut(address token, address destination, address receiver, uint256 amount) external auth {
        require(destinations[token][destination] >= amount, "UserEscrow/transfer-failed");
        require(
            /// @dev transferOut can only be initiated by the destination address or an authorized admin.
            ///      The check is just an additional protection to secure destination funds in case of compromized auth.
            ///      Since userEscrow is not able to decrease the allowance for the receiver,
            ///      a transfer is only possible in case receiver has received the full allowance from destination address.
            receiver == destination || (ERC20Like(token).allowance(destination, receiver) == type(uint256).max),
            "UserEscrow/receiver-has-no-allowance"
        );
        destinations[token][destination] -= amount;

        SafeTransferLib.safeTransfer(token, receiver, amount);
        emit TransferOut(token, receiver, amount);
    }

UserEscrow contract designed to hold tokens for specific destinations and restrict their transfer only to those destinations, by wards. However, the issue arises when the predefined destination address is blacklisted by the USDC contract, leading to permanent fund lock-up.

Tools Used

Mnaual review

Recommended Mitigation Steps

To address this issue, it is recommended to implement a privileged function within the UserEscrow contract that should allow authorized parties to change the predefined destination address.

Assessed type

ERC20

[c4-pre-sort]

raymondfam marked the issue as sufficient quality report

[c4-pre-sort]

raymondfam marked the issue as duplicate of #32

[c4-judge]

gzeon-c4 changed the severity to QA (Quality Assurance)