Core Contracts

Summary

In the BoostController contract, the updateUserBoost() function is vulnerable due to the absence of access control, allowing unauthorized delegation overwrite. Malicious actors can exploit this by calling updateUserBoost() with any delegator's address and any pool's address, bypassing the intended flow of delegateBoost(). This allows attackers to overwrite existing delegations without the delegator's consent, leading to a Denial of Service (DoS) where users cannot delegate to their desired pools. The intended behavior should be:

• Users delegate their boost to a pool using delegateBoost().

• Only permissioned entities, such as the delegatee pool or authorized roles, should be able to call updateUserBoost().

Vulnerability Details

Lack of Access Control in updateUserBoost()

The updateUserBoost() function currently allows any address to call it with arbitrary user and pool addresses, leading to unauthorized delegation manipulation. The relevant code is as follows:

This implementation lacks any role-based access control or authorization checks, allowing anyone to:

• Call updateUserBoost() with another user's address as the user parameter.

• Specify any pool address, effectively overwriting the delegation.

Code Analysis

The vulnerability arises due to the absence of checks, such as:

• Verifying if the caller is the user or an authorized entity (e.g., the delegatee pool or an admin role).

• Ensuring the action follows a valid delegation flow initiated by delegateBoost().

Proof of Concept

Scenario

1. Bob delegates her boost to Pool A using delegateBoost(), which records her choice internally.

2. A malicious actor, Mallory, notices the lack of access control in updateUserBoost().

3. Mallory calls updateUserBoost(Bob, PoolB) without Bob's consent.

4. The function updates Bob's boost to be delegated to Pool B, effectively overwriting her original choice.

5. Bob is now unknowingly delegating her boost to Pool B, leading to a DoS as she cannot delegate to her intended pool.

Code (PoC)

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, This confirmed the overwrite vulnerability, as no checks were in place to prevent unauthorized delegation changes.

Impact

• Denial of Service (DoS) for users unable to delegate their boost to the intended pools.

• Unauthorized delegation manipulation, leading to governance or reward distribution issues.

• Potential for financial instability due to altered boost calculations.

Tools Used

• Manual Review

• Foundry

Recommendations

Implement Access Control

Add role-based access control or authorization checks to ensure only permitted entities can update user boosts:

This change ensures that only the delegator or an authorized role can modify the boost, preserving the integrity of the delegation flow.

Restrict updateUserBoost() to Delegatees

Limit updateUserBoost() calls to delegatee pools that have received a valid delegation from the user via delegateBoost().