Submitted by 0xA5DF, also found by Trust and V_B
HolographOperator.sol#L316
Theres a check at line 316 that verifies that theres enough gas left to execute the HolographBridge.bridgeInRequest() with the gasLimit set by the user, however the actual amount of gas left during the call is less than that (mainly due to the 1/64 rule, see below).
An attacker can use that gap to fail the job while still having the executeJob() function complete.
The owner of the bridged token would loose access to the token since the job failed.
Besides using a few units of gas between the check and the actual call, theres also a rule that only 63/64 of the remaining gas would be dedicated to an (external) function call. Since there are 2 external function calls done (nonRevertingBridgeCall() and the actual call to the bridge) ~2/64 of the gas isnt sent to the bridge call and can be used after the bridge call runs out of gas.
The following PoC shows that if the amount of gas left before the call is at least 1 million then the execution can continue after the bridge call fails:
Output of PoC:
Side note: due to some bug in forge _inboundMessageCounter would be considered warm even though its not necessarily the case. However in a real world scenario we can warm it up if the selected operator is a contract and weer using another operator contract to execute a job in the same tx beforehand.
Reference for the 1/64 rule - EIP-150. Also check out evm.codes.
Modify the required amount of gas left to gasLimit + any amount of gas spent before reaching the call(), then multiply it by 32/30 to mitigate the 1/64 rule (+ some margin of safety maybe).
gzeon (judge) commented:
Trust (warden) commented:
0xA5DF (warden) commented:
Trust (warden) commented:
0xA5DF (warden) commented:
gzeon (judge) commented:
Trust (warden) commented:
gzeon (judge) commented:
Trust (warden) commented:
alexanderattar (Holograph) confirmed and commented:
ACC01ADE (Holograph) resolved:
