search

sherlock-audit / 2023-07-perennial-judging

2 stars 1 forks source link

feelereth - the _latestStale() check is vulnerable to timestamp manipulation by miners #106

Closed sherlock-admin closed 1 year ago

sherlock-admin commented 1 year ago

feelereth

high

the _latestStale() check is vulnerable to timestamp manipulation by miners

Summary

The _latestStale() check compares timestamps to determine if the latest oracle is stale. However, timestamps can be manipulated by miners to some extent. An attacker who is a miner could manipulate timestamps to trick the contract into thinking the latest oracle is stale when it is not

Vulnerability Detail

This Link compares the timestamp from the latest oracle version to the timestamp when that version was committed. If the version timestamp is greater, it returns false. A miner could manipulate this by:

  1. Calling latest() to get the latest oracle version
  2. Checking if _latestStale() would return true for that version
  3. If so, mining a block with a timestamp that makes _latestStale() return false
  4. Calling request() before the next miner mines a block, to update the oracle based on the manipulated timestamp This would trick _latestStale() into thinking the latest oracle is not stale, when it actually is.

Impact

An attacker can prevent the oracle from updating to the current provider when it should. They could manipulate the outdated oracle values.

Code Snippet

https://github.com/sherlock-audit/2023-07-perennial/blob/main/perennial-v2/packages/perennial-oracle/contracts/Oracle.sol#L112-L117

Tool used

Manual Review

Recommendation

timestamps should not be fully trusted. Instead of comparing exact timestamps, have a buffer window of allowed timestamp drift

sherlock-admin commented 1 year ago

2 comment(s) were left on this issue during the judging contest.

141345 commented:

l

panprog commented:

invalid because scenario doesn't make sense