Summary

A critical vulnerability was identified in the initialization process of the scrvUSD Oracle contract. The contract fails to assign the DEFAULT_ADMIN_ROLE to any address during deployment, resulting in a permanently locked administrative state. This prevents future administrative actions, including granting roles required for price parameter verification and unlock time verification. The issue effectively renders the contract unmanageable and reduces it to its initial immutable state.

Vulnerability Details

The vulnerability is located in the __init__ function of the scrvUSD Oracle contract. The function properly initializes the access control system and sets the role administrators for PRICE_PARAMETERS_VERIFIER and UNLOCK_TIME_VERIFIER, but critically fails to assign the DEFAULT_ADMIN_ROLE to the contract deployer (msg.sender).

The contract uses the access_control module from Snekmate implements role-based access control similar to OpenZeppelin's AccessControl. In this implementation, roles must be explicitly granted, and the DEFAULT_ADMIN_ROLE is essential for granting other roles.

This vulnerability creates a "locked" administrative state where:

1. No address has the DEFAULT_ADMIN_ROLE

2. Without an admin, no address can be granted the PRICE_PARAMETERS_VERIFIER role

3. Without an admin, no address can be granted the UNLOCK_TIME_VERIFIER role

4. The contract cannot be updated or managed by anyone

Impact

The impact of this vulnerability is severe:

1. Complete Loss of Administrative Control: No entity can perform administrative actions on the contract, including critical functions that likely require admin privileges.

2. Inability to Update Oracle Parameters: The contract's intended functionality as an oracle for scrvUSD share prices is severely compromised as parameters cannot be updated or verified.

3. Permanent Contract Immutability: The contract becomes permanently locked in its initial state, with no possibility for updates, upgrades, or bug fixes.

4. Broken Integration Ecosystem: Any systems relying on this oracle for price feeds (the StableSwap pool mentioned in the contract comments) will be affected, potentially leading to cascading failures in the protocol ecosystem.

5. Potential Financial Losses: Depending on how the oracle is used, this could lead to incorrect pricing information being used in financial calculations, potentially resulting in financial losses for users or the protocol.

This vulnerability essentially renders the contract unusable for its intended purpose as an adaptable oracle with administrative controls.

Tools Used

• Manual code review

• Understanding of role-based access control patterns in smart contracts

• Knowledge of Snekmate's implementation of access control

Recommendations

1. Immediate Fix: Modify the __init__ function to assign the admin role to the deployer:

1. Comprehensive Testing: Implement thorough testing of role assignment and administrative functions to ensure proper functionality after deployment.

2. Multi-Admin Setup: Consider implementing a multi-signature or DAO-based admin setup to provide additional security and prevent single points of failure.

3. Role Verification: Add post-deployment verification to confirm that roles have been properly assigned.

4. Documentation: Document the administrative structure and required roles in the contract comments and external documentation.

5. Event Logging: Add events for administrative actions to provide transparency and aid in debugging.

By implementing these recommendations, the contract can be secured and its intended functionality restored, allowing for proper management of the scrvUSD oracle within the wider ecosystem.