Christmas Dinner

First Flight #31
Beginner FriendlyFoundrySolidity
100 EXP
View results
Submission Details
Severity: low
Invalid

Possible incorrect function timestamps

Summary

The functions beforeDeadline(), setDeadline()and most importantly changeParticipationStatus() are all depended on the block.timestamp for checking and setting deadline. However, this introduces a vulnerability. Malicious miners could potentially manipulate the block.timestamp, leading to inaccuracies in the recorded deadline timestamps. This can have implications for time-sensitive operations such as checking if a user calls function before the deadline.

Vulnerability Details

Let's check the changeParticipationStatus() and how it works. The function allows a user to set their participant status to true only when their status right now is false and block.timestamp <= deadline .

function changeParticipationStatus() external {
// ...
else if(!participant[msg.sender] && block.timestamp <= deadline) {
participant[msg.sender] = true;
// ...
}

The block.timestamp represents the time at which the block is mined and is determined by the miner. Although Ethereum has mechanisms in place to prevent timestamp manipulation, miners still have some degree of control over the block timestamp within certain limits, known as block time drift. This drift allows miners to adjust the timestamp by a small range, which introduces a possibility of timestamp manipulation.

For example, in the above function assume the current block.timestamp when the transaction is submitted is 1000 seconds. The deadline is 1010 seconds, so there are 10 seconds left. However, the miner manipulates the timestamp and adds additional 15 seconds which is within the allowed block time drift range.

(1000 + 15) <= 1010
1015 <= 1010 // false

So, the user is unable to become a participant, even though they submitted the transaction within the expected time range.

If there was a buffer of 15 seconds the example would look like this:

(1000 + 15) <= (1010 + 15)
1015 <= 1025 // true

Now, the user is able to become participant.

Impact

  1. The issue could affect users who submit transactions close to the deadline, especially if they rely on exact timing.

  2. Prevents users from executing last-moment actions (e.g., requesting a refund or changing participation status) if they rely on precise timing.

Tools Used

Manual review

Recommendations

Add a buffer period or grace period everywhere the block.timestamp is used both for checking and setting the deadline.

The buffer period can add an additional level of security.

// beforeDeadline()
block.timestamp > deadline + buffer
// changeParticipationStatus()
block.timestamp <= deadline + buffer
// setDeadline()
deadline = block.timestamp + (_days * 1 days) + buffer
Updates

Lead Judging Commences

0xtimefliez Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!