Stake Contract Instances can be hijacked in reorg

[c4-bot-10]

Lines of code

https://github.com/code-423n4/2024-05-olas/blob/3ce502ec8b475885b90668e617f3983cea3ae29f/registries/contracts/staking/StakingFactory.sol#L168

Vulnerability details

Impact

There is a vulnerability in the createStakingInstance function, which uses the create2 method for creating staking contract instances. The vulnerability arises from the use of a salt based on the blockchain ID and an incrementing nonce, making the code susceptible to block reorganization (reorg) attacks.

Vulnerability Description
The createStakingInstance function generates a new staking contract instance using the create2 method. The salt for this operation is derived from the blockchain ID and an incrementing nonce. Since the blockchain ID remains constant within a single blockchain, the salt's uniqueness relies solely on the nonce, which increments with each new contract creation. This dependency on the incrementing nonce makes the function vulnerable to block reorg attacks.

Code Snippet
The relevant code section is shown below:

uint256 localNonce = nonce;
// Get salt based on chain Id and nonce values
bytes32 salt = keccak256(abi.encodePacked(block.chainid, localNonce));
// Get the deployment data based on the proxy bytecode and the implementation address
bytes memory deploymentData = abi.encodePacked(type(StakingProxy).creationCode,
    uint256(uint160(implementation)));

// solhint-disable-next-line no-inline-assembly
assembly {
    instance := create2(0x0, add(0x20, deploymentData), mload(deploymentData), salt)
}
// Check that the proxy creation was successful
if (instance == address(0)) {
    revert ProxyCreationFailed(implementation);
}

A blockchain reorganization (reorg) occurs when a longer or more valid chain of blocks replaces the current chain, causing some blocks to be discarded and transactions to be reordered. Reorgs can lead to inconsistencies in transaction processing and are more common in proof-of-stake (PoS) blockchains, where reorgs can reach significant depths.

Attack Scenario
An attacker can exploit this vulnerability by performing the following steps:

Initial Contract Creation: The attacker observes the nonce value used for the latest contract creation and waits for a transaction that creates a new staking instance.

Blockchain Reorganization: During a block reorg, the attacker's malicious transactions are included in a longer chain, invalidating the original chain where the legitimate contract creation was intended.

Front-Running the Nonce: The attacker quickly submits a transaction using the same nonce value as the original transaction. Since the nonce has been incremented, the attacker's transaction gets the intended salt.

Deployment of Malicious Contract: The attacker successfully deploys their malicious staking contract instance with the same salt, resulting in the overwriting or duplication of contract addresses.

Exploitation: Users that has interacted with the first legitimate instance, unknowingly have now sent funds or staked in the malicious contract. This allows the attacker to siphon funds or perform other malicious actions.

Proof of Concept

Examples of other findings of this issue or similar:

code-423n4/2024-03-abracadabra-money-findings#211

code-423n4/2023-07-amphora-findings#233

code-423n4/2023-01-rabbithole-findings#661

Tools Used

Recommended Mitigation Steps

Make salt more unique by including msg.sender for example

Assessed type

Other