Core Contracts

Summary

The BoostController contract contains a critical vulnerability in the delegateBoost and updateUserBoost functions. These issues allow a malicious delegator to:

1. Delegate more boost than they actually have, leading to unfair reward distribution, governance manipulation, and financial instability.

2. Artificially reduce a pool’s totalBoost to zero, impacting the pool’s reward distribution and voting power.

These issues arise because:

• The delegateBoost function incorrectly validates delegation eligibility using the veToken balance instead of the actual boost balance calculated via _calculateBoost.

• The updateUserBoost function fails to account for artificially high delegations, allowing attackers to drain a pool’s totalBoost.

This vulnerability can be exploited to severely damage the protocol’s governance, financial stability, and fairness in reward distribution.

Vulnerability Details

1. Incorrect Validation in delegateBoost

The delegateBoost function currently checks the user’s veToken balance instead of their actual boost balance before allowing delegation:

Why This Is Wrong?

• The veToken balance does not represent the actual boost balance available for delegation.

• Attackers can bypass the check by holding a large veToken balance, even if they don’t have the required boost balance.

• This allows attackers to delegate excessive boosts, granting unfair governance power and reward distribution.

Correct Approach:

• Use _calculateBoost to validate the actual boost balance before allowing delegation.

• The correct condition should be:

2. Pool Boost Draining via updateUserBoost

A malicious delegator can manipulate the updateUserBoost function to artificially reduce a pool’s totalBoost to zero.

How the Attack Works?

1. Malicious Delegation:

   • The attacker delegates a large amount (e.g., 12000) to a pool.

   • The contract accepts the delegation due to incorrect veToken validation (as explained earlier).

2. Calling updateUserBoost:

   • The function calculates the old boost (which is 12000) and a new boost (e.g., 10500).

   • If the pool’s totalBoost was initially 1500, the following code executes:

   if (newBoost >= oldBoost) {

   poolBoost.totalBoost = poolBoost.totalBoost + (newBoost - oldBoost);

   } else {

   poolBoost.totalBoost = poolBoost.totalBoost - (oldBoost - newBoost);

   }

   • Since oldBoost - newBoost = 12000 - 10500 = 1500, and the pool’s totalBoost was only 1500, the result is:

   poolBoost.totalBoost = poolBoost.totalBoost - 1500; // Becomes 0

   • The entire pool’s boost gets wiped out, completely eliminating its influence in reward distribution and governance.

Impact of This Attack:

• Zeroing Out a Pool’s Boost: Attackers can strategically drain a pool’s boost, making it lose all influence in governance and financial rewards.

• Economic Damage: This could result in a loss of rewards for legitimate users, discouraging participation in the protocol.

• Governance Takeover: By repeatedly executing this attack, malicious actors can shift power towards specific pools they control.

Proof of Concept

Exploit Scenario: Boost Delegation Manipulation

1. Setup:

   • Assume an attacker has 500 veTokens but has a true boost balance of only 200.

   • They call delegateBoost(to, 12000, duration), and because the function checks veToken balance instead of boost balance, the transaction succeeds.

   • The pool’s totalBoost is now incorrectly inflated.

2. Executing the Attack (Boost Drain):

   • The attacker calls updateUserBoost.

   • The new boost is calculated as 10500, while the old boost was 12000.

   • The pool’s totalBoost is 1500, and after the operation, it becomes 0, eliminating the pool’s influence.

Code PoC (similar to above scenario)

To demonstrate this vulnerability, the following Proof of Concept (PoC) is provided. The PoC is written using the Foundry tool.

1. Step 1: Create a Foundry project and place all the contracts in the src directory.

2. Step 2: Create a test directory and a mocks folder within the src directory (or use an existing mocks folder).

3. Step 3: Create all necessary mock contracts, if required.

4. Step 4: Create a test file (with any name) in the test directory.

5. Step 5: Add the following test PoC in the test file, after the setUp function.

6. Step 6: To run the test, execute the following commands in your terminal:

7. Step 7: Review the output.

As demonstrated, the test confirms that the (delegatee) pools's boost total amount becomes zero and it can't be fixed even after removing malicious delegation.

Impact

1. Governance Manipulation

• Attackers can delegate massive boosts to influence governance votes unfairly.

• Pools with legitimate users lose governance control.

2. Reward Distribution Exploitation

• Attackers can drain pools of boost and redirect rewards to attacker-controlled pools.

• This leads to unfair economic gains for malicious actors.

3. Financial Instability

• The protocol’s stability relies on accurate boost calculations.

• By delegating fake boosts and zeroing out pool boosts, attackers create financial chaos.

Tools Used

• Manual Reviwe

• Foundry

Recommendations

1. Fix delegateBoost Validation

Current Code:

Fixed Code (Correct Boost Check):

2. Prevent Pool Boost Draining in updateUserBoost

Current Code:

Fixed Code (Preventing Negative Boost Impact):