safdie - Time manipulation via `block.timestamp` will allow miners to manipulate `block.timestamp` to shift funding rate calculations in `FundingRateFacetImpl.sol`

[sherlock-admin4]

safdie

Medium

Time manipulation via block.timestamp will allow miners to manipulate block.timestamp to shift funding rate calculations in FundingRateFacetImpl.sol

Summary

The contract relies heavily on block.timestamp for epoch and funding window calculations. Malicious miners could manipulate block.timestamp to shift funding rate calculations, especially given the require checks around funding windows.

Root Cause

The block.timestamp is a value set by miners, which means it can be manipulated to a certain extent. If a contract relies on block.timestamp for critical operations, such as funding rate calculations or cooldown periods, it can be susceptible to manipulation by malicious actors who may influence the block mining process. In the chargeFundingRate function of the FundingRateFacetImpl contract, there are several checks that rely on block.timestamp: https://github.com/sherlock-audit/2024-09-symmio-v0-8-4-update-contest/blob/main/protocol-core/contracts/facets/FundingRate/FundingRateFacetImpl.sol#L41-L49 If a miner can influence the block time, they could potentially manipulate the funding payment logic to cause the funding rate to be paid prematurely or to miss a payment window. This could be done by deliberately adjusting the block time.

Internal pre-conditions

No response

External pre-conditions

No response

Attack Path

Example calculation:

1. Assume the current block.timestamp is T.
2. Suppose windowTime is set to 1 hour. If a miner mines a block slightly after T, they could make the block.timestamp effectively T + 1.
3. By manipulating the timestamp, they might bypass certain checks, allowing them to perform actions that would otherwise be restricted.

Impact

1. Attackers could exploit this vulnerability to receive funding payments at unintended times, leading to financial gains at the expense of others.
2. Manipulated timestamps could disrupt the intended flow of the contract, causing actions to be executed out of order or incorrectly.
3. If multiple parties are impacted by manipulated timestamps, it could lead to market inefficiencies and potential loss of trust in the platform.

PoC

No response

Mitigation

1. When possible, use block numbers for critical logic, as they cannot be manipulated like timestamps.
2. Implement delays or require multiple confirmations before executing critical functions that rely on block.timestamp. This can help to mitigate potential manipulation.
3. Set reasonable thresholds for allowable discrepancies in time, ensuring that only reasonable variations in block.timestamp are accepted.

   require(block.timestamp >= lastActionTime + MIN_TIME_DIFFERENCE, "Action too soon");