Submitted by EV_om
https://github.com/code-423n4/2024-05-olas/blob/3ce502ec8b475885b90668e617f3983cea3ae29f/tokenomics/contracts/staking/GnosisDepositProcessorL1.sol#L77https://github.com/code-423n4/2024-05-olas/blob/3ce502ec8b475885b90668e617f3983cea3ae29f/tokenomics/contracts/staking/GnosisDepositProcessorL1.sol#L90
The GnosisDepositProcessorL1 contract is responsible for bridging OLAS tokens and messages from L1 to the GnosisTargetDispenserL2 contract on Gnosis Chain. When calling claimStakingIncentives() or claimStakingIncentivesBatch() on the Dispenser contract for a nominee on Gnosis, it calls _sendMessage() internally to send the incentive amounts and any necessary funds to L2.
If the transferAmount has been reduced to 0 due to sufficient withheld funds on Gnosis, it only sends a message via the Arbitrary Message Bridge (AMB) to process the claimed incentives.
However, when sending this message, the caller provides a gasLimitMessage parameter to specify the gas limit for executing the message on L2. There is no lower bound enforced on this value, although it is required to be >= 100 internally by the AMB. If the caller sets gasLimitMessage too low, the message will fail to execute on L2 due to out of gas.
Because the Gnosis AMB provides no native way to replay failed messages, if a message fails due to insufficient gas, the claimed staking incentives will be irredeemable on L2. An attacker could intentionally grief the protocol by repeatedly claiming incentives with an insufficient gas limit, causing them to be lost.
While the protocol could call processDataMaintenance() on L2 with the data from the cancelled message to recover, this would require passing a governance proposal. Given that this attack can be carried out any number of times (e.g. as often as possible and with a different target each time), this can considerably impact the functioning of the protocol hence I believe Medium severity is justified.
An attacker can make legitimately claimed staking incentives irredeemable on L2 by setting an insufficient gas limit when claiming. This would require governance intervention each time to recover the lost incentives.
Do not allow users to directly specify the gasLimitMessage. Instead, have the GnosisDepositProcessorL1 contract calculate the required gas based on the number of targets and stakingIncentives being processed. A small buffer can be added to account for any minor differences in gas costs.
Alternatively, implement a way to replay failed messages from the AMB, so that irredeemable incentives can be recovered without requiring governance intervention.
kupermind (Olas) acknowledged
Olas mitigated:
Varun_05 (warden) commented:
