First Flight #7: Horse Store

Summary

At the same time the same horse can be happy on Arbitrum and unhappy on Ethereum due to the way in which block.timestamp works on Arbitrum.

Vulnerability Details

The project will be deployed on Arbitrum and Ethereum. Also, the HorseStore::isHappyHorse relies on block.timestamp to check the time when the horse was last fed. But the block.timestamp on Arbitrum works differently.

In the Arbitrum documentation is said:

https://docs.arbitrum.io/for-devs/concepts/differences-between-arbitrum-ethereum/block-numbers-and-time#block-timestamps-arbitrum-vs-ethereum

Impact

Due to the way in which the block.timestamp works on Arbitrum it is possible the following scenario:

Bob feeds the horse with Id 1 at 15 hour on 18 January. On the next day (19 January) at 17 hour Alice checks if the horse with Id 1 is happy. The contract is deployed on Arbitrum and the block.timestamp can return value that is 24 hours earlier than the current time. So, the HorseStore::isHappyHorse function returns true, because for the function is 17 hour on 18 January and the horse was fed 2 hours ago. But actually the horse was fed 26 hours ago and it is unhappy. On the Ethereum the horse will be unhappy.

Tools Used

Manual Review

Recommendations

Ensure that the return value of the HorseStore::isHappyHorse function is reliable on every chain that the project is deployed.