Timestamp dependency, block.timestamp is vulnerable to manipulation

[code423n4]

Lines of code

https://github.com/ProjectOpenSea/seaport/blob/5de7302bc773d9821ba4759e47fc981680911ea0/contracts/lib/AmountDeriver.sol#L58

Vulnerability details

Impact

The vulnerability of block.timestamp in smart contracts is related to the fact that the timestamp of a block is provided by the miner who mined the block. As a result, the timestamp is not guaranteed to be accurate or to be the same across different nodes in the network. In particular, an attacker can potentially mine a block with a timestamp that is favorable to them, known as "selective packing".

For example, an attacker could mine a block with a timestamp that is slightly in the future, allowing them to bypass a time-based restriction in a smart contract that relies on block.timestamp. This could potentially allow the attacker to execute a malicious action that would otherwise be blocked by the restriction.

Proof of Concept

• contracts/lib/AmountDeriver.sol#L58 => elapsed = block.timestamp - startTime;

Tools Used

• Private self-made tool for static analysis
• Manual Review, Remix IDE

Recommended Mitigation Steps

Developers should avoid using block.timestamp in their smart contracts and instead use an alternative timestamp source, such as an oracle, that is not susceptible to manipulation by a miner.

References:

• Timestamp dependence | Solidity Best Practices for Smart Contract Security
• What Is Timestamp Dependence?

[0age]

contested; room for manipulation is severely overstated and using block numbers in place of timestamps has a host of issues associated with it

[HickupHH3]

Disagree as well. If we talk about mainnet, block times can realistically be assumed to be exactly 12s. Of course, for other chains, it isn't as deterministic, but manipulation of it isn't easy to pull off, + even if one does, the POC lacks sufficient explanation of its impact.

[c4-judge]

HickupHH3 marked the issue as unsatisfactory: Insufficient proof