Skip to content

Missing freshness check in L2LPTDataCache.finalizeCacheTotalSupply leads to underpaid (or overpaid) rewards in the next rounds #664

Description

@rickstaa

Summary

The current implementation of the L1LPTDataCache.cacheTotalSupply and its counterpart L2LPTDataCache.finalizeCacheTotalSupply does not implement a freshness check of the received _totalSupply amount via a cross-chain message. This is a problem, since cross-chain messages sent via Arbitrum's native retryable tickets can fail immediate automatic redemption, but can be redeemed manually much later, when bridged totalSupply is severely outdated. This can, in the worst case, affect the amount of rewards delegates will receive on L2 – this number is currently used only by the Minter to determine rewards at the round start.

Root causes

  1. Preventable automatic redemption. Permissionless L1LPTDataCache.cacheTotalSupply function accepts arbitrary gasLimit value used by the automatic redeemer.
  2. A potential for severely outdated totalSupply amount. Native retryable ticket can be kept alive indefinitely by calling ArbRetryableTx.keepalive(bytes32 ticketId)) every 7 days.
  3. Missing freshness check. The receiving L2 method finalizeCacheTotalSupply does not validate that the message was sent recently; no expiration is implemented at the application level.

Why it's not an issue

  • This hasn't been a problem so far: the totalSupply on L1 hasn't changed since the migration to Arbitrum (and the deployment of the contracts in question).
  • Triggering the attack currently requires either burning LPT tokens on L1 or bridging a massive amount of LPT from Arbitrum back to the Ethereum Mainnet. This makes the likelihood extremely low.
  • The issue is monitored offchain. If an outdated ticket is found, it can be pemissionlessly redeemed by anyone, effectively cancelling the attack even before the value gets outdated.

Out of scope for the bug bounty

Reports targeting missing freshness check inside L2LPTDataCache.finalizeCacheTotalSupply method will be closed as known issues and are not eligible for rewards under the Livepeer Immunefi bug bounty program, unless the report shows how the severity can be escalated beyond what is already shown above.

References

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    known-issueDocumented, acknowledged non-remediated behavior is not bounty-eligible.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions