On May 22nd at 00:24 BST, the Arbitrum Foundation notified the Security Council of the need to perform a potential Emergency Action. Following review, the Security Council decided to execute the upgrade which was completed at 18:50 BST on May 24th.
In the following, we provide an overview of the vulnerability and the required Security Council Emergency Action.
Key point: No funds were ever at risk
A vulnerability was discovered in the L1 Timelock Contract which forms part of the Arbitrum governance smart contract system. The contract inherits the renounceRole() from AccessControlUpgradeable.sol. This function can renounce the PROPOSER_ROLE in the L1 Timelock Contract.
The Arbitrum Bridge has the PROPOSER_ROLE in the L1 Timelock Contract. All constitutional proposals, such as protocol upgrades, are sent from Arbitrum One to the L1 Timelock through the bridge. This requires the Arbitrum Bridge to hold the PROPOSER_ROLE. Otherwise the cross-chain message with the upgrade will be rejected by the L1 Timelock.
The renounceRole() function only verifies that the immediate caller is the Arbitrum Bridge contract. It does not verify that the underlying cross-chain message originated from the Core Governor contract on Arbitrum One. As a result, anyone could submit a cross-chain message from L2 to L1 instructing the bridge to renounce the PROPOSER_ROLE on the L1 Timelock Contract.
If exploited, the DAO would lose its ability to execute constitutional governance AIPs. It is a recoverable situation as the Security Council can restore the PROPOSER_ROLE to the bridge contract. Additionally, the cross-chain message must wait in the seven-day queue for the fraud proof window, during which the Security Council can intervene and deploy a mitigation before execution.
Problem: The inherited public renounceRole() function lacked the onlyCounterpartTimelock modifier in the L1 Timelock contract.
Impact: The missing verification check allows unauthenticated L2 to L1 messages to renounce the role and halt future constitutional proposal from executing.
Risk: The cross-chain message must pass through the 7-day queue, where the Security Council can step in to cancel it. Additionally, the Security Council can restore access if the exploit were to occur.
Security Council Actions
The Security Council approved a transaction that disallows the call with the specific payload to call the renounceRole() function from passing through the bridge.
The Security Council signed the following transactions to update the configuration:
No external audit of the payload was required. It adds a single hash check in Bridge.executeCall() that rejects one specific call payload with CallNotAllowed(). There is no impact on user transactions and requires no node upgrades.
A smart contract fix will be included in a future ArbOS upgrade to rectify the vulnerability, but the Emergency Action taken should neutralize it and prevent its exploitation in the near-future.
Timeline of Events
- 00:24 BST on May 22nd:
- The Security Council was notified about the vulnerability on Signal.
- 18:10 BST on May 24th:
- Transaction with the Security Council Emergency Action was prepared and ready to be signed.
- 18:50 BST on May 24th:
- The transaction was signed by the Security Council and executed on Ethereum.