009.md

Original Lace Sheep

Medium

Missing OpenZeppelin Upgradeable Initializations will Impact Protocol Security and Functionality

Summary

Multiple contracts failing to initialize inherited OpenZeppelin upgradeable contracts will cause a systemic issue for protocol users as uninitialized contracts may operate with improper state variables and access controls.

Root Cause

In the following contracts, there are missing initializations of inherited OpenZeppelin upgradeable contracts:

https://github.com/sherlock-audit/2024-11-teller-finance-update/blob/main/teller-protocol-v2-audit-2024/packages/contracts/contracts/LenderCommitmentForwarder/extensions/LenderCommitmentGroup/LenderCommitmentGroup_Smart.sol#L81-L88

https://github.com/sherlock-audit/2024-11-teller-finance-update/blob/main/teller-protocol-v2-audit-2024/packages/contracts/contracts/TellerV2.sol#L49-L52

https://github.com/sherlock-audit/2024-11-teller-finance-update/blob/main/teller-protocol-v2-audit-2024/packages/contracts/contracts/LenderCommitmentForwarder/SmartCommitmentForwarder.sol#L51-L55

1. In LenderCommitmentGroup_Smart.sol, the contract inherits ReentrancyGuardUpgradeable but fails to call __ReentrancyGuard_init()
2. In TellerV2.sol, the contract inherits OwnableUpgradeable but fails to call __Ownable_init()
3. In SmartCommitmentForwarder.sol, the contract inherits ReentrancyGuardUpgradeable but fails to call __ReentrancyGuard_init()

Internal pre-conditions

1. Contracts must be deployed and initialized through their respective proxy patterns
2. For LenderCommitmentGroup_Smart and SmartCommitmentForwarder, reentrancy protection would need to be required for a function execution
3. For TellerV2, ownership functionality would need to be invoked

External pre-conditions

No external pre-conditions required as this is an implementation issue.

Attack Path

For TellerV2:

1. Contract is deployed and initialized without proper __Ownable_init()
2. Initial owner state may be improperly set
3. Ownership functions could behave unexpectedly or fail
4. Critical owner-only functions may become inaccessible or improperly secured

For LenderCommitmentGroup_Smart and SmartCommitmentForwarder:

1. Contracts are deployed without proper __ReentrancyGuard_init()
2. Reentrancy guard state variables are not properly initialized
3. nonReentrant modifier may not provide expected protection
4. Potential for reentrancy attacks on protected functions

Impact

The affected parties (protocol and users) face multiple risks:

1. LenderCommitmentGroup_Smart:

• Missing reentrancy protection could allow unauthorized reentrant calls
• Critical functions marked with nonReentrant may be vulnerable
• Potential loss of funds through reentrancy attacks

2. TellerV2:

• Ownership functionality may be compromised
• Administrative functions could become inaccessible
• Security of owner-protected functions may be compromised

3. SmartCommitmentForwarder:

• Similar to LenderCommitmentGroup_Smart, reentrancy attacks possible
• Protected functions may be vulnerable to exploitation
• Potential loss of funds or unauthorized operations

The overall protocol security could be significantly compromised, potentially leading to unauthorized access, fund loss, or contract functionality failure.

PoC

No response

Mitigation

1. Add proper initialization calls in the affected contracts' initialize() functions:

// LenderCommitmentGroup_Smart.sol
function initialize(...) initializer {
    __ReentrancyGuard_init();
    // Rest of initialization logic
}

// TellerV2.sol
function initialize(...) initializer {
    __Ownable_init();
    // Rest of initialization logic
}

// SmartCommitmentForwarder.sol
function initialize(...) initializer {
    __ReentrancyGuard_init();
    // Rest of initialization logic
}

2. Ensure the initializer modifier is used to prevent multiple initializations