Report #30288

Report ID#30288

Report type

Smart Contract

Has PoC?

Yes

Target

https://etherscan.io/address/0xDEb0f00071497a5cc9b4A6B96068277e57A82Ae2

Impacts

• Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Depot.sol supports permit function which can be affected by Dos making them unusable

Vulnerability Details

Depot.sol allows ERC20 permit for following functions in contract:

1. permitToken()
2. permitDeposit()
3. permitDeposits()

These functions allows users to permit tokens and deposits via ERC20 permit functionality.

For example, permitToken() uses beanstalk.permitToken() to permit the tokens to spender on his behalf.

    function permitToken(
        address owner,
        address spender,
        address token,
        uint256 value,
        uint256 deadline,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external payable {
        beanstalk.permitToken(owner, spender, token, value, deadline, v, r, s);
    }

This supports ERC20 permit functionality by which users could spend the tokens by signing an approval off-chain.

The issue is that while the transactions for permitToken(), permitDeposit() and permitDeposits() is in mempool, anyone could extract the signature parameters from the call to front-run the transaction with direct permit call. Since, the contract is deployed on Ethereum mainnet so this issue is possible due to presence of mempool.

This issue is originally submitted by Trust security aka Trust to various on chain protocols and the issue is confirmed by reputed protocols.

To understand the issue in detail, Please refer below link:

link: https://www.trust-security.xyz/post/permission-denied

An attacker can extract the signature by observing the mempool, front-run the victim with a direct permit, and revert the function call for the user. "In the case that there is no fallback code path the DOS is long-term (there are bypasses through flashbots in some chains, but that's a really bad scenario to resort to)." as stated by Trust Security.

This issue would indeed increase the approval for the user if the front-run got successful. But as the permit is already been used, the call to permitToken(), permitDeposit() and permitDeposits()will revert making whole transaction revert. Thus making the victim not able to make successful call to permitToken(), permitDeposit() and permitDeposits() by using permit() function.

Impact Details

Users will not be able to use the permit functions for important functions like permitToken(), permitDeposit() and permitDeposits() so this function would be practically unusable and users functionality would be affected due to griefing attack by attacker.

References

https://etherscan.io/address/0xDEb0f00071497a5cc9b4A6B96068277e57A82Ae2?utm_source=immunefi

https://www.trust-security.xyz/post/permission-denied

Recommendation to fix

Wrap the ERC20 permit function calls in try catch block in functions.

References

https://www.trust-security.xyz/post/permission-denied

Proof of concept

Consider a normal scenario,

1. Bob wants to permit the tokens or deposit token via permit so he calls either permitToken() or permitDeposit(). To be noted, the contract is deployed on Ethereum so there is presence of mempool.
2. Alice observes the transactions in mempool and extract the signature parameters from the call to front-run the transaction with direct permit call.
3. Alice transaction got successful due to high gas fee paid by her to minor by front running the Bob's transaction.
4. This action by Alice would indeed increase the approval for the Bob since the front-run got successful.
5. But as the permit is already been used by Alice so the call to permitToken() or permitDeposit() will revert making whole transaction revert.
6. Now, Bob will not able to make successful call to permitToken() or permitDeposit() by using permit() function. This is due to griefing attack by Alice. She keep repeating such attack as the intent in griefing.