Beedle - Oracle free perpetual lending

Summary

Passing block.timestamp as the deadline parameter in the swap function of Uniswap Router can introduce several security problems. The deadline parameter is meant to specify the maximum timestamp by which the transaction must be confirmed, and using block.timestamp can lead to the following issues.

Vulnerability Details

Front-running attacks, Timestamp manipulation, Stale transactions

Impact

Front-running attacks:
Front-running attacks involve malicious actors observing pending transactions on the blockchain and then executing their own transactions with more favorable terms before the original transaction is confirmed. By using block.timestamp as the deadline, you are revealing your intended execution time, making it easier for attackers to anticipate and manipulate your transaction. They can quickly submit their transactions with slightly higher gas fees and a more favorable rate to outpace your trade.

Timestamp manipulation:
Using block.timestamp as the deadline allows an attacker to manipulate their own system clock to influence the outcome of transactions. They can change the timestamp of their transaction to be earlier than the actual block timestamp, effectively tricking the contract into considering their transaction as valid even though it should have expired.

Stale transactions:
Setting the deadline to block.timestamp means that your transaction will become invalid immediately after the current block timestamp. If there are network delays or congestions, your transaction may not get included in a block before the deadline expires, resulting in a failed transaction. This can lead to unexpected results and potentially financial losses.

Tools Used

Manual

Recommendations

To address these security problems, it's essential to use a reasonable and future-oriented timestamp as the deadline parameter. You should avoid using block.timestamp directly, as it can leak information and be susceptible to manipulation. Instead, calculate a suitable deadline based on the current block's timestamp and add a reasonable buffer to account for potential network delays.

For example, you can use block.timestamp + some_offset as the deadline, where some_offset is a small value (e.g., a few minutes or seconds) to provide a reasonable window for the transaction to be confirmed while still avoiding potential front-running attacks.