Beedle - Oracle free perpetual lending

Summary

The Fees.sellProfits function that interact with Uniswap Router do not have a deadline parameter, but passing block.timestamp.
This enables pending transactions to be maliciously executed at a later point.

Vulnerability Details

AMMs provide their users with an option to limit the execution of their pending actions, such as swaps or adding and removing liquidity. The most common solution is to include a deadline timestamp as a parameter. If such an option is not present, users (in that case the "Fees Manager") can unknowingly perform bad trades:

1. "Fee Manager" wants to swap 100 tokens for 1 WETH.
   The transaction is submitted to the mempool, however, "Fee Manager" chose a transaction fee that is too low for miners to be interested in including her transaction in a block. The transaction stays pending in the mempool for extended periods, which could be hours, days, weeks, or even longer.

2. When the average gas fee dropped far enough for the transaction to become interesting again for miners to include it, her swap will be executed. In the meantime, the price of the token could have drastically changed. So the Fee Manager will get less than 1 ETH. He has unknowingly performed a bad trade due to the pending transaction he forgot about.

An even worse way this issue can be maliciously exploited is through MEV:

1. The swap transaction is still pending in the mempool. Average fees are still too high for miners to be interested in it. The price of tokens has gone up significantly since the transaction was signed, meaning "Fee Manager" would receive a lot more ETH when the swap is executed. But that also means that her maximum slippage value (sqrtPriceLimitX96 and minOut in terms of the Fees contracts) is outdated and would allow for significant slippage.

2. A MEV bot detects the pending transaction. Since the outdated maximum slippage value now allows for high slippage, the bot sandwiches Fee Maanger, resulting in significant profit for the bot and significant loss for the Fee Manager.

Since Fees.sol directly builds on Uniswap V3, such deadline parameters should also be offered to the sellProfits function. However, there it uses block.timestamp.

A malicious miner can hold the transaction, which may be being done in order to decrease the token price down borrow and sell it for example (short), than to allow the transaction to be executed. A miner can also just hold it until maximum slippage is incurred.

Impact

Loss of funds for the protocol every time the admin sells tokens to WETH using the Fees.sellProfits function

Tools Used

VSCode

Recommendations

Let the user supply a deadline parameter to the sellProfits function instead of using block.timestamp.