Users can gas grief the operator in the `V3Automation.sol`

[c4-bot-1]

Lines of code

https://github.com/code-423n4/2024-06-krystal-defi/blob/main/src/V3Automation.sol#L84

Vulnerability details

Impact

The operator may spend gas on the execute call without receiving any value in return.

Proof of Concept

The Krystal protocol allows users to automate actions such as exiting or reranging positions. When certain conditions are met, the Krystal-controlled wallet (bot) calls the execute function with the user's instructions, and a portion of the tokens is paid as fees to the protocol.

There are several issues with this approach:

• The tokens deducted as fees for gas usage may have no value. For instance, a user could deploy two basic ERC20 contracts (TOK1, TOK2), create a Uniswap pool with them, mint an LP token, and request the Krystal automator to rebalance it. Upon completing the execute transaction, the protocol receives TOK1 and TOK2 as fees, but these tokens may have no market value and cannot be exchanged for ETH or USDC. Consequently, the protocol spends gas without any profit.
• A user could create a malicious token that performs costly computations within the approve or transfer calls. This would waste the operator's gas when attempting to execute actions with such tokens and eventually revert.

Tools Used

Manual review

Recommended Mitigation Steps

Implement a whitelist for tokens and verify if LP NFT token0 and token1 is in it.

Assessed type

Token-Transfer

[3docSec]

Provisionally marking satisfactory

[c4-judge]

3docSec marked the issue as satisfactory

[c4-judge]

3docSec marked the issue as selected for report

[3docSec]

The caller (who is privileged with OPERATOR_ROLE) is expected to simulate the transaction and evaluate its profitability before submitting & losing the gas cost. This is as far as I know a standard assumption in gasless transactions

[c4-judge]

3docSec marked the issue as unsatisfactory: Invalid

[k4zanmalay]

The caller (who is privileged with OPERATOR_ROLE) is expected to simulate the transaction and evaluate its profitability before submitting & losing the gas cost.

@3docSec I agree, but there are a couple of other problems:

• the griefer can revert a transaction based on block.timestamp (e.g revert if block.timestamp % 2 == 0), this way simulation can succeed while the real transaction fails;
• the issue with worthless tokens is still not solved, even if the simulation is able to retrieve the token value in USD from the Uniswap, if the griefer is the only liquidity provider for the Uniswap pool, he can remove the liquidity, therefore tokens that were received as the gas payment will lose their value.

[3docSec]

Hi @k4zanmalay,

considering the two points:

the griefer can revert a transaction based on block.timestamp

Callbacks with logical revert are a new attack vector that was not covered in the initial report, so we really can't consider this point.

even if the simulation is able to retrieve the token value in USD from the Uniswap, if the griefer is the only liquidity provider for the Uniswap pool

this too would be an error from the operator because they would be accepting gas payments in a low-liquidity token and using spot price instead of i.e. a well-established TWAP or, even better, Chainlink feed.

So accepting payment in i.e. the attacker's own coin or similar would certainly be a miss in due diligence from the operator.