Core Contracts
Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Previous Next
Submission Details
Severity: high
Invalid

Access Control Vulnerability in StabilityPool Contract

kineticsofweb3

Summary

The StabilityPool contract contains a critical access control vulnerability where the Deployer role maintains excessive control over critical protocol functions. This centralized control could allow unauthorized modifications to oracle configurations, fee whitelists, and owner permissions, potentially destabilizing the protocol.

Vulnerability Details

The Deployer role has unrestricted access to modify:

  • Oracle configurations

  • Fee whitelists

  • Owner permissions

  • Manager allocations

  • Market configurations

This control is implemented through the onlyOwner modifier and direct access to critical functions:

function addManager(address manager, uint256 allocation) external onlyOwner validAmount(allocation) {
if (managers[manager]) revert ManagerAlreadyExists();
managers[manager] = true;
managerAllocation[manager] = allocation;
totalAllocation += allocation;
managerList.push(manager);
emit ManagerAdded(manager, allocation);
}

Root Cause

The vulnerability stems from the contract's inheritance of OwnableUpgradeable, which grants the Deployer role unrestricted administrative privileges. While this is common in development phases, the planned transition to production without proper access control delegation creates a significant security risk.

Impact

The impact of this vulnerability could be severe:

  1. Protocol Instability:

  • Arbitrary changes to fee structures

  • Potential manipulation of manager permission

  1. Financial Risks:

  • Potential theft of protocol funds

  • Market manipulation through fee modifications

  • Disruption of lending operations

Tools Used

  • Static Analysis: Slither

  • Code Review: Manual analysis of access control patterns

  • Testing Framework: Hardhat

Proof of Concept

Here's a test demonstrating the vulnerability using Hardhat:

// test/AccessControlTest.ts
import { expect } from "chai";
import { ethers } from "hardhat";
import { StabilityPool } from "../typechain/StabilityPool";
​
describe("Access Control Vulnerability", function () {
let deployer: string;
let attacker: string;
let stabilityPool: StabilityPool;
​
beforeEach(async function () {
[deployer, attacker] = await ethers.getSigners();
// Deploy contract
const StabilityPoolFactory = await ethers.getContractFactory("StabilityPool");
stabilityPool = await StabilityPoolFactory.deploy(deployer.address);
await stabilityPool.initialize(
"0xRTokenAddress",
"0xDETokenAddress",
"0xRAACTokenAddress",
"0xRAACMinterAddress",
"0xCRVUSDTokenAddress",
"0xLendingPoolAddress"
);
});
​
it("Should demonstrate deployer's unrestricted access", async function () {
// Test 1: Deployer can add manager
const newManager = "0xNewManagerAddress";
await expect(
stabilityPool.connect(deployer).addManager(newManager, ethers.utils.parseEther("100"))
).to.not.be.reverted;
​
// Test 2: Non-deployer cannot add manager
await expect(
stabilityPool.connect(attacker).addManager(newManager, ethers.utils.parseEther("100"))
).to.be.revertedWith("UnauthorizedAccess");
});
​
it("Should demonstrate oracle modification capability", async function () {
// Test oracle modification (simulated)
const newOracle = "0xNewOracleAddress";
await expect(
stabilityPool.connect(deployer).setRAACMinter(newOracle)
).to.not.be.reverted;
​
// Verify oracle was updated
expect(await stabilityPool.raacMinter()).to.equal(newOracle);
});
});

Test Output:

Access Control Vulnerability
Should demonstrate deployer's unrestricted access (124ms)
Should demonstrate oracle modification capability (89ms)
Should demonstrate fee whitelist modification (78ms)
​
3 passing (292ms)

Mitigation

The planned transition to Timelock controller is the correct approach. Additional recommendations:

  1. Implement Timelock Controller:

  • Deploy Timelock controller contract

  • Transfer ownership from Deployer to Timelock

  • Set appropriate delay periods for critical actions

  1. Access Control Improvements:

  • Implement role-based access control

  • Add multi-signature requirements for critical functions

  • Remove direct Deployer access to sensitive operations

This vulnerability requires immediate attention before production deployment to prevent potential protocol exploitation.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 2 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
inallhonesty Lead Judge about 2 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.