## Summary Not considering leap seconds in the conversion performed from TAI64 to UNIX timestamp leads to an error of 27 seconds when setting `block_timestamp` in the config. ## Finding Description [Fuel uses the TAI64 format](https://docs.fuel.network/docs/fuels-ts/utilities/date-conversion/#formats) internally to represent timestamps. Because of this, it is required for Redstone to perform a conversion from TAI64 to UNIX so that the timestamps from the payload can be adequately compared to the current block timestamp. This conversion is done when building the config that will be passed to the `process_input` method: ```rust // File: prices.sw #[storage(read)] fn process_payload(feed_ids: Vec, payload_bytes: Bytes) -> (Vec, u64) { let config = Config { feed_ids, signers: storage.signers.load_vec(), signer_count_threshold: storage.signer_count_threshold.read(), block_timestamp: timestamp() - (10 + (1 << 62)), }; process_input(payload_bytes, config) } ``` Essentially, the current implementation performs the following steps to carry out the TAI64→UNIX conversion: 1. Fetch the current block timestamp in TAI64 format, given by Sway’s `timestamp()` function 2. Substract `1 << 62`. This is done because TAI64 is represented by 64-bit values. The timestamp `s` refers to: - the TAI second beginning exactly 2^62 - `*s*` seconds before the beginning of 1970 TAI, if `*s*` is between 0 inclusive and 2^62 exclusive - the TAI second beginning exactly `*s*` - 2^62 seconds after the beginning of 1970 TAI, if `*s*` is between 2^62 inclusive and 2^63 exclusive. Because of this, it is always compulsort to substract 2^62. 3. Substract 10. This must be done as TAI64 does not consider leap seconds (although UNIX and UTC formats do). Because of this, 10 is substracted to account for the leap seconds that are actually considered in UNIX timestamps. The problem with the current implementation is that the amount of leap seconds substracted is incorrect. As shown in the previous snippet, currently 10 seconds are substracted, which represents the amount of leap seconds up to 1972 (the leap-second system was introduced at the beginning of 1972, at that point UTC was TAI minus 10 seconds). Since 1972, an additional 27 leap seconds have been added to UTC (and UNIX) (it). This makes the TAI64→UNIX timestamp conversion be off by 27 seconds, which could greatly affect Redstone, given that timestamp validations are performed in order to ensure that the payload prices are not too delayed/advanced, and to set clear rules to which timestamps must be considered valid and which can’t: ```rust // File: processor.sw pub fn process_input(bytes: Bytes, config: Config) -> (Vec, u64) { let payload = Payload::from_bytes(bytes); config.validate_timestamps(payload); ... } ``` ```rust // File: validation.sw pub fn validate_timestamp(i: u64, timestamp: u64, block_timestamp: u64) { if (block_timestamp > timestamp) { if (block_timestamp - timestamp > MAX_DATA_TIMESTAMP_DELAY_SECONDS) { log(timestamp); log(block_timestamp); revert(TIMESTAMP_OUT_OF_RANGE + i + 1000); } } if (timestamp > block_timestamp) { if (timestamp - block_timestamp > MAX_DATA_TIMESTAMP_AHEAD_SECONDS) { log(timestamp); log(block_timestamp); revert(TIMESTAMP_OUT_OF_RANGE + i + 2000); } } } ``` The outcome of the issue is timestamp conversions always being 27 seconds bigger than they should, which could lead to two incorrect scenarios taking place: - Packages could be considered valid before the actual `MAX_DATA_TIMESTAMP_AHEAD_SECONDS` expected delay. In this case, prices that should still not be accepted can be accepted, which breaks the expected behavior of the system. - Packages whose timestamp should still be considered valid as per the `MAX_DATA_TIMESTAMP_DELAY_SECONDS` allowed delay might not be considered valid. In this case, the issue leads to a DoS, when in reality packages with these timestamps should be accepted. ## Impact Explanation The impact of this issue is high. A 27 second difference would usually not be considered of great importance for regular protocols, but Redstone’s case is different. Its oracles (and usually all oracles) are designed to provide prices and consider them valid during a specific time window (in Redstone case, we can submit prices advanced up to `MAX_DATA_TIMESTAMP_AHEAD_SECONDS`, and delayed up to `MAX_DATA_TIMESTAMP_DELAY_SECONDS`). The issue can make valid prices not be accepted by the protocol, or prices that should still not be valid to already be considered as valid. Specifically, the chance of getting DoS’ed by the contracts rejecting a price that should be valid is around 3%, while the chance of being able to submit prices ahead of time when it shouldn’t be possible is around 15%. ## Likelihood Explanation Likelihood for the issue is also high, as the timestamp is never properly set due to the wrong conversion. ## Recommendation Account for the full 37-second leap seconds that have passed until the current date when performing the timestamp conversion: ```diff // File: prices.sw #[storage(read)] fn process_payload(feed_ids: Vec, payload_bytes: Bytes) -> (Vec, u64) { let config = Config { feed_ids, signers: storage.signers.load_vec(), signer_count_threshold: storage.signer_count_threshold.read(), - block_timestamp: timestamp() - (10 + (1 << 62)), + block_timestamp: timestamp() - (37 + (1 << 62)), }; process_input(payload_bytes, config) } ``` ## Additional resources - [TAI64, explained](https://www.notion.so/In-audit-fff81a0d280a81b2b3e1dc704b3e83cb?pvs=21) - [UTC, TAI, and UNIX time](https://cr.yp.to/proto/utctai.html) - [Leap seconds table - NASA](https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt)

Contest	Position	Date	Payout
redstone-oracle	3 / 186	September 2024	$3,745
stakeup-bloomv2	43 / 363	October 2024	$165
zetachain-protocol	44 / 339	August 2024	$159

spuriousdragon

Top competitions