Potential Front-Running and DoS Vulnerabilities due to EIP-2612 Usage

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0xf83ec142dee1fbdac67614b3e5385b645d83abd069579a44233ad05d602b0639 Severity: low

Description: Description\

The depositWithSignature function utilizes the permit function as defined by EIP-2612 to approve and deposit assets in a single transaction. While this implementation improves user experience by reducing the need for separate transactions, it introduces potential risks:

1. Front-Running Risk: Since the permit function can be called by any party who has access to the signed message, a malicious actor can observe the transaction in the mempool and front-run the permit function. This would cause the subsequent deposit call to revert as the permit function would already have been executed by the attacker.

2. Denial of Service (DoS): The design of depositWithSignature unconditionally depends on the success of the permit function. If the permit function is front-run, it could cause the transaction to fail, resulting in a denial of service. This is especially problematic if the permit call is part of a more extensive process, as it could prevent the process from completing.

3. Phishing Risk: EIP-2612 introduces the potential for phishing attacks where users might be tricked into signing a permit that looks benign but actually authorizes the transfer of their tokens to a malicious actor.

Attack Scenario\

1. Front-Running Scenario: Bob tries to deposit assets using the depositWithSignature function. Eve, observing the mempool, sees Bob’s transaction and submits the permit transaction first. When Bob’s transaction is executed, it fails because the permit has already been used.

2. Phishing Scenario: Eve convinces Bob to sign a hash that supposedly gives him access to a token airdrop. However, the signed message is actually a permit for the transfer of Bob’s tokens to Eve’s address. Eve then uses this signature to steal Bob’s tokens.

Attachments

1. Proof of Concept (PoC)

function depositWithSignature(
        uint256 assets,
        address receiver,
        uint256 deadline,
        bool approveMax,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external nonReentrant returns (uint256 shares) {
        uint256 amount = approveMax ? type(uint256).max : assets;
        asset.permit(msg.sender, address(this), amount, deadline, v, r, s);
        return (deposit(assets, receiver));
    }

1. Revised Code

Consider implementing checks within the depositWithSignature function to handle potential front-running of the permit call. For instance, ensure that the logic allows for fallback paths if the permit function has already been called, or structure the contract such that the deposit call can proceed under certain conditions even if the permit was front-run.

[0xRizwan]

depositWithSignature() function is from staking contracts so its OOS.