28623 - [SC - Low] Timelock transaction that consume more then _ g...

Submitted on Feb 22nd 2024 at 17:00:05 UTC by @OxDEADBEEF for Boost | Puffer Finance

Report ID: #28623

Report type: Smart Contract

Report severity: Low

Target: https://etherscan.io/address/0xd9a442856c234a39a81a089c06451ebaa4306a72

Impacts:

  • Contract fails to deliver promised returns, but doesn't lose value

  • Temporary freezing of funds for at least 1 hour

  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

Description

Brief/Intro

The timelock's executeTransaction does not validate that it has enough gas to execute the underlying transaction. Because of eip-150's 63/64 gas rule - transactions that need more then 209_595 gas to execute can fail due to out of gas while the parent transaction transaction has enough gas (1/64) to successfully finish the transaction

Vulnerability Details

executeTransaction calls the target with the callData.

As can be seen above - After calling the target, not much gas is needed to finish the transaction. After EIP-150 the EVM reserves 1/64 of the gas consumed target so that executeTransaction can finish the transaction. As seen in the POC - the minimum amount of gas target needs to consume in order to leave enough gas for the transaction to succeed is 209_595.

If target needs more then that - the target can fail due to out of gas while the executeTransaction and the transaction will be deleted from the queue:

  1. executeTransaction is called with 214_640 gas.

  2. target consumes all 209_595 gas and runs out

  3. Upper transaction did not revert and queue[txHash] = 0; .

I suggest to check after the call to target if there is more then needed gasleft

Impact Details

When the OPERATIONS_MULTISIG calls executeTransaction to execute a long waited transaction it can by mistake or maliciously set the exact gas needed for executeTransaction to succeed but the underlying call to target will fail.

This means that the transaction would need to be listed again in the timelock. If the call to target resolves around movement of funds or any other critical operation - it will be delayed

Proof of Concept

Add the following function to Timelock.t.sol

To run the test:

Expected output:

As can be seen the transaction succeeds while gasConsumingFunc fails

Last updated

Was this helpful?