Liquid Staking

Summary

A reentrancy vulnerability has been identified in the OperatorVCS.sol smart contract within the stake.link platform. Specifically, the updateDeposits function allows external contracts (vaults) to execute arbitrary code during its execution without adequate reentrancy protection. This vulnerability can be exploited by malicious vaults to manipulate internal state variables, potentially leading to unauthorized reward distributions and financial losses.

Vulnerability Details

Malicious Vault Contract

1. Contract Declaration and Imports

Explanation:

The MaliciousVault contract begins by specifying the Solidity version and importing the IOperatorVault interface. This interface defines the functions that the vault must implement, ensuring compatibility with the OperatorVCS contract.

2. Contract Definition and State Variables

Explanation:

• OperatorVCS public operatorVCS;
  This state variable holds the address of the OperatorVCS contract, allowing the malicious vault to interact with it.

• bool public attackInitiated;
  A boolean flag to track whether the reentrancy attack has been initiated. This ensures the attack is only executed once.

3. Constructor

Explanation:

The constructor accepts the address of the OperatorVCS contract and initializes the operatorVCS state variable. This setup is crucial for the malicious vault to interact with the vulnerable contract.

4. Overriding updateDeposits Function

Explanation:

• Reentrancy Attack Execution:
  The updateDeposits function is overridden to include a reentrant call to OperatorVCS.updateDeposits. The first time this function is called, it sets attackInitiated to true and attempts to re-enter the OperatorVCS contract.

• Dummy Return Values:
  After attempting the reentrant call, the function returns fixed dummy values for deposits, principal, and rewards, ensuring that the malicious behavior does not disrupt the expected flow unless the reentrancy is successful.

5. Implementing Other IOperatorVault Functions

Explanation:

To fully comply with the IOperatorVault interface, the MaliciousVault implements all required functions. These implementations are either empty or return fixed dummy values, ensuring that the malicious behavior is isolated to the overridden updateDeposits function.

Test Contract for Reentrancy Attack

1. Contract Declaration and Imports

Explanation:

The test contract begins by specifying the Solidity version and importing necessary dependencies:

• forge-std/Test.sol: Provides testing utilities.

• OperatorVCS.sol: The vulnerable contract under test.

• MaliciousVault.sol: The malicious contract designed to exploit the vulnerability.

• ERC20.sol: For deploying a mock ERC20 token to simulate reward distributions.

2. Mock Reward Token Contract

Explanation:

• Purpose:
  The RewardToken contract is a mock ERC20 token used to simulate the rewards distributed by the OperatorVCS contract.

• Constructor:
  Mints an initial supply of 1,000,000 RTK to the contract's own address.

• mint Function:
  Allows minting additional tokens to any address, facilitating the simulation of reward distributions to the malicious vault.

3. Test Contract Definition and State Variables

Explanation:

• State Variables:

  • operatorVCS: Instance of the vulnerable OperatorVCS contract.

  • rewardToken: Instance of the mock RewardToken.

  • maliciousVault: Instance of the MaliciousVault designed to exploit the vulnerability.

  • stakingPool: Simulated address representing the staking pool.

  • owner: The deployer of the test contract, typically the test runner.

4. setUp Function

Explanation:

• Deployment Sequence:

  1. Reward Token:
     Deploys the RewardToken contract to simulate rewards.

  2. OperatorVCS:
     Deploys and initializes the OperatorVCS contract with dummy parameters. The actual token address is set to address(0) for testing purposes.

  3. MaliciousVault:
     Deploys the MaliciousVault, passing the address of the OperatorVCS contract to its constructor.

  4. Adding Malicious Vault:
     Adds the MaliciousVault to the OperatorVCS contract using the addVault function. This step assumes that the test contract has ownership privileges to perform this action.

5. Test Function: testReentrancyAttack

Explanation:

• Minting Tokens:
  The test mints 10,000 RTK tokens to the MaliciousVault, simulating the scenario where the vault holds rewards.

• Simulating External Call:
  Using vm.prank(stakingPool), the test simulates a call from the stakingPool address to OperatorVCS.updateDeposits. This triggers the updateDeposits function, which in turn calls the malicious vault's overridden updateDeposits function.

• Assertion:
  The test asserts that attackInitiated is set to true, indicating that the reentrancy attack was successfully initiated by the MaliciousVault.

• Additional Assertions:
  Further checks can be implemented to verify the integrity of the OperatorVCS contract's state after the attack, ensuring that no unauthorized state changes occurred.

Expected Outcome

When the updateDeposits function is called by the stakingPool, the MaliciousVault attempts to re-enter the OperatorVCS.updateDeposits function. If the vulnerability exists, the reentrant call will manipulate the internal state of OperatorVCS, potentially allowing the attacker to alter reward distributions or other critical variables. The assertion assertTrue(maliciousVault.attackInitiated(), "Reentrancy attack was not initiated"); verifies whether the reentrant attack was successfully initiated.

If the contract lacks proper reentrancy protections, the test will pass, demonstrating that the attack was possible. Conversely, if reentrancy guards are in place, the attack should fail, and the test will indicate that the vulnerability is mitigated.

Impact

Exploiting this reentrancy vulnerability can have severe consequences, including:

• Unauthorized Reward Manipulation: Attackers can manipulate the operatorRewards variable to divert rewards to unauthorized addresses.

• Inconsistent State Variables: Manipulation of totalDeposits and totalPrincipalDeposits can disrupt the financial integrity of the staking platform.

• Financial Losses: Users and the platform may suffer significant financial losses due to unauthorized withdrawals and reward distributions.

• Erosion of Trust: Successful exploitation can undermine user confidence in the platform's security and reliability.

Given the critical nature of staking and reward distribution mechanisms, this vulnerability poses a high risk to the platform's financial stability and user trust.

Tools Used

Manual Review

Recommendations

To mitigate the identified reentrancy vulnerability in OperatorVCS.sol, the following measures should be implemented:

1. Implement Reentrancy Guards

Utilize OpenZeppelin's ReentrancyGuard to prevent reentrant calls to vulnerable functions.

Explanation:

The nonReentrant modifier ensures that the function cannot be called while it is already in execution, effectively preventing reentrant attacks.

2. Update State Before External Calls

Ensure that all state variables are updated before making any external calls to minimize the window for potential reentrancy.

Explanation:

By updating unclaimedOperatorRewards before transferring tokens, the contract ensures that any subsequent reentrant calls cannot exploit the outdated state.