Summary

The codebase contains the delegatecall instruction, which violates the EEA EthTrust Security Level [S] requirements. The delegatecall instruction allows an external contract to manipulate the state of the calling contract, leading to potential security vulnerabilities.

Vulnerability Details

The delegatecall instruction was identified at the following locations:

• File: contracts/base/ExecutionHelper.sol

  • Line: 110

    if iszero(delegatecall(gas(), delegate, result, callData.length, codesize(), 0x00)) {

  • Line: 129

    success := delegatecall(gas(), delegate, result, callData.length, codesize(), 0x00)

• File: contracts/Nexus.sol

  • Line: 221

    (bool success, ) = bootstrap.delegatecall(bootstrapCall);

The delegatecall instruction enables an external contract to manipulate the state of a contract that calls it, as the code is executed with the caller's balance, storage, and address. This can lead to various security issues such as unauthorized access, reentrancy attacks, and state manipulation.

Impact

Using delegatecall can lead to significant security risks, including:

• Unauthorized Access: External contracts can modify the state of the caller contract, potentially leading to unauthorized access and changes.

• Reentrancy Attacks: The delegatecall instruction can be exploited for reentrancy attacks, allowing attackers to repeatedly call back into the contract and manipulate its state.

• State Manipulation: External contracts can alter the state variables of the caller contract, leading to unintended behaviors and potential loss of funds.

Tools Used

• Manual code review

Recommendations

To prevent vulnerabilities in Solidity’s delegatecall function, it is crucial to follow best practices. Here are some recommendations to enhance the security of your contracts:

1. Avoid Using delegatecall:

   • Avoid using the delegatecall function unless absolutely necessary. Evaluate whether there are alternative ways to achieve the desired functionality without introducing potential vulnerabilities.

2. Use Explicit Naming for State Variables:

   • Use explicit naming for state variables to avoid the “state variable shadowing” issue. This helps to differentiate between the calling contract’s variables and the called contract’s variables, reducing the chances of unintended modifications.

3. Implement Proper Access Control:

   • Implement proper access control mechanisms to prevent unauthorized access to critical functions and variables. Restrict the usage of the delegatecall function to trusted contracts only.

4. Comprehensive Input Validation:

   • Implement comprehensive input validation and sanitization checks in your contract’s functions. This helps to prevent unexpected behavior and ensures that the contract is not susceptible to malicious inputs.

5. Remove delegatecall Usage:

   • Refactor the code to eliminate the use of delegatecall. Consider using safer alternatives such as direct calls or carefully controlled proxy patterns that do not expose the same level of risk.

6. Document the Necessity:

   • If the delegatecall instruction is essential for the contract’s functionality, document the necessity and provide a thorough explanation of why its use is critical. Include detailed descriptions of the security measures in place to mitigate associated risks.

By addressing these recommendations, the security risks associated with the use of delegatecall in the ExecutionHelper.sol and Nexus.sol contracts can be significantly mitigated.