Core Contracts

Regnum Aurum Acquisition Corp
HardhatReal World AssetsNFT
77,280 USDC
View results
Submission Details
Severity: low
Invalid

Unused EMERGENCY_ADMIN role in BoostController contract

Summary

The BoostController contract defines a constant for an emergency admin role:

bytes32 public constant EMERGENCY_ADMIN = keccak256("EMERGENCY_ADMIN");

This role is granted to the deployer (along with other roles), but it is never used in any function within the contract. In particular, the emergency shutdown function setEmergencyShutdown is restricted solely to accounts with the MANAGER_ROLE rather than utilizing the EMERGENCY_ADMIN role as might be intended.

Vulnerability Details

  • Definition and Granting:
    The EMERGENCY_ADMIN role is defined and granted in the constructor:

    _grantRole(EMERGENCY_ADMIN, msg.sender);

    However, it is never referenced or checked in any function within the contract.

  • Functionality Misalignment:
    The emergency shutdown functionality is implemented as follows:

    function setEmergencyShutdown(bool paused) external onlyRole(MANAGER_ROLE) {
    if (paused) {
    _pause();
    } else {
    _unpause();
    }
    emit EmergencyShutdown(msg.sender, paused);
    }

    Since only the MANAGER_ROLE is allowed to trigger an emergency shutdown, accounts with the EMERGENCY_ADMIN role do not have any special privileges for emergency control. This might be contrary to the intended design where the emergency function should be available to a dedicated emergency role.

  • Implications:

    • Role Misconfiguration: Users might assume that accounts with EMERGENCY_ADMIN can control emergency shutdowns, but in reality, this function is restricted to managers.

    • Access Flexibility: The current implementation limits the pool of accounts that can pause/unpause the contract to only those with MANAGER_ROLE, potentially reducing operational flexibility during emergencies.

Impact

  • Low Severity Impact:
    This issue does not directly lead to a security vulnerability or loss of funds. However, it creates confusion about access control and might restrict emergency actions to fewer accounts than intended.

  • Operational Considerations:
    In the event of an emergency, if the intended design was to allow a broader set of emergency admins to perform shutdowns, the current implementation may delay or complicate emergency responses.

Tools Used

Manual review

Recommendations

Review Role Assignments:
Verify the intended access model for emergency shutdowns. If the design was to allow accounts with EMERGENCY_ADMIN to trigger an emergency shutdown, modify the function to include this role. For example:

function setEmergencyShutdown(bool paused) external {
if (!hasRole(MANAGER_ROLE, msg.sender) && !hasRole(EMERGENCY_ADMIN, msg.sender)) {
revert UnauthorizedCaller();
}
if (paused) {
_pause();
} else {
_unpause();
}
emit EmergencyShutdown(msg.sender, paused);
}

Role Cleanup (if not intended):
If the design does not require a dedicated emergency admin role, consider removing the unused role to avoid confusion.

Updates

Lead Judging Commences

inallhonesty Lead Judge 7 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.

Give us feedback!