eOracle Middleware (delta)
Smart Contract Security Assessment
April 10, 2024
SUMMARY
ABSTRACT
This report covers a small add-on to our earlier audit of Eoracle middleware. The audit covers a single smart contract that acts as a chain manager, whitelisting operators with specific roles.
SETTING & CAVEATS
This audit covers the EOChainManager contract in the public repository https://github.com/Eoracle/eoracle-middleware of the protocol at commit 6e84fca30464cd724723ce3867494437f23de6d6
.
One of the remarks of the earlier audit report is particularly relevant to the EOChainManager contract and should be kept in mind for correct contract operation. This scenario is not precluded in the EOChainManager code, so it should be protected against during deployment of the middleware.
_
Among others, the implementation should anticipate problems such as:_
- …
- gracefully handling possible front-running of operations, such as calls to EORegistryCoordinator::setChainManager, e.g., to register an operator while no chain manager is set, or while an older chain manager is still in control.
VULNERABILITIES & FUNCTIONAL ISSUES
This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:
- User or system funds can be lost when third-party systems misbehave.
- DoS, under specific conditions.
- Part of the functionality becomes unusable due to a programming error.
- Breaking important system invariants but without apparent consequences.
- Buggy functionality for trusted users where a workaround exists.
- Security issues which may manifest when the system evolves.
Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.
CRITICAL SEVERITY
[No critical severity issues]
HIGH SEVERITY
[No high severity issues]
MEDIUM SEVERITY
[No medium severity issues]
LOW SEVERITY
[No low severity issues]
CENTRALIZATION ISSUES
The chain manager is a permissioned entity, as expected for its role in whitelisting operators.
OTHER / ADVISORY ISSUES
This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.
The standard upgradability convention is for contracts to reserve a total of 50 storage slots. This is usually achieved by maintaining a fixed-sized array state variable and adjusting its size accordingly when new state variables are introduced. The EOChainManager
contract unexpectedly breaks the above-mentioned convention by having 50+1 = 51 storage slots.
EOChainManager
abstract contract EORegistryCoordinatorStorage is IEORegistryCoordinator {
// @notice The address of eoracle middleware RegistryCoordinator
address public registryCoordinator;
...
uint256[50] private __GAP;
}
Breaking the convention for a single contract might prove error-prone, so we recommend that the __GAP
array be made to have a fixed-size length of 49.
In order to prevent someone from initializing the implementation contract, it is recommended that the Initializable::_disableInitializers
function be called from inside the constructor of EOChainManager
With Cancun’s network release SELFDESTRUCT
does not clear the contract’s code after the deployment tx is completed. As a result, implementation contracts that are taken over no longer run the risk of freezing the proxy contract. However, it’s still recommended not to allow the storage variables of the implementation contract to be set.
EOChainManager::updateOperator
is intended to be called only by the EORegistryCoordinator
contract. However, the above-mentioned function is not used anywhere inside the corresponding contract.
EOChainManager
function updateOperator(
address operator,
uint96[] calldata newStakeWeights
) external view onlyRegistryCoordinator {
// For now just whitelisting. EO chain integration to come.
}
The code ChainManager
contract has the compile pragma ^0.8.12
. For deployment, we recommend no floating pragmas, i.e., a specific version, so as to be confident about the baseline guarantees offered by the compiler. Version 0.8.12
, in particular, has some known bugs, which we do not believe affect the correctness of the contracts.
DISCLAIMER
The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.
ABOUT DEDAUB
Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.