Shawler - attacker can grief repayBorrowWithERC20Permit and stakeWithERC20Permit via permit front-running

[sherlock-admin2]

Shawler

Medium

attacker can grief repayBorrowWithERC20Permit and stakeWithERC20Permit via permit front-running

Summary

Potential griefing vector of stakeWithERC20Permit and repayBorrowWithERC20Permit having a pre-signed approval ('permit') signature attached
(e.g., no profit motive for an attacker but spoils UX for users of the protocol) by front-running the 'token.permit' calls with intercepted from mempool signatures.

repayBorrowWithERC20Permit

stakeWithERC20Permit

Root Cause

The stakeWithERC20Permit and repayBorrowWithERC20Permit functions integrate the permit feature to combine approval and transaction processes into a single step, streamlining operations by eliminating the need for two separate transactions.

ERC20Permit employs a nonce mapping for safeguarding against replay attacks. When a signature is validated and processed, the corresponding nonce is incremented, rendering the same signature unusable for subsequent transactions. Both the stakeWithERC20Permit and repayBorrowWithERC20Permit functions require users to authorize their tokens for use by the UserManagerERC20 and UErc20 contract addresses, respectively, as spenders. Users must submit these transactions along with their digital signatures—specified by uint8 v, bytes32 r, bytes32 s.

reference lido permit issue

Attack Path

address owner = victim’s address
address spender = UserManagerERC20 contract address

uint256 amount = `amount` replicated from the pending transaction
uint256 deadline = `deadline` replicated from the pending transaction
uint8 v = `v` replicated from the pending transaction
bytes32 r = `r` replicated from the pending transaction
bytes32 s = `s` replicated from the pending transaction

This valid signature is accepted by the token contract, which then updates the nonce accordingly. As a result, when the original user transaction attempts to process, it fails due to the already updated nonce.

Impact

When a user’s transaction resides in the mempool awaiting confirmation, an attacker could potentially exploit this by using the observed signature to preemptively execute the token.permit function with the publicly available parameters.

Mitigation

function trustlessPermit(
        address token,
        address owner,
        address spender,
        uint256 value,
        uint256 deadline,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) internal {
        // Try permit() before allowance check to advance nonce if possible
        try IERC20Permit(token).permit(owner, spender, value, deadline, v, r, s) {
            return;
        } catch {
            // Permit potentially got frontran. Continue anyways if allowance is sufficient.
            if (IERC20(token).allowance(owner, spender) >= value) {
                return;
            }
        }
        revert("Permit failure");
    }

reference

Duplicate of #65