Ethereum Vault Connector Security Audit

Audit Report Revisions

Audit Overview

We were tasked with performing an audit of the Euler Finance codebase and in particular their Ethereum Vault Connector module.

High-Level Description

The EVC module represents a security-conscious router via which users can interact and associate themselves with vaults that integrate with the EVC system.

The EVC system itself exposes multiple mechanisms via which DeFi interactions are performed in a controlled environment, guaranteeing that post-execution checks (such as solvency evaluations for borrowing protocols) can be mandated whenever a user interacts with their collateral which is in the custody of collateral vaults.

Sub-Account Model

Within the EVC, a particular account can ultimately own up to 256 accounts inclusive of their own by using a prefix-association pattern which ignores the 8 rightmost bits of the address's representation.

While the security of a particular address's uniqueness is reduced from 160 to 152 bits as a result of this pattern, the EVC router will associate a particular 256 address range with the "first" address that interacts with the protocol.

As such, even if a theoretical attack was carried out to identify an EOA with a common prefix as the original user who captured a particular range, the identified address would be unusable as the owner of the prefix would have already been registered.

Based on the above, a practical attack should never manifest even if the security of 152 bits was considered breached as it would be conditional on an account expressing interest to register its prefix, an on-chain race condition capturing the prefix before them, and them having approved certain collateral vaults with assets beforehand that would be registered by the attacker and would ultimately be compromised.

Specification

The codebase was validated against its whitepaper as well as specification, and three discrepancies were observed one of which is considered an invariant breach under non-standard circumstances; to note, this breach does not constitute a security vulnerability.

From an optimizational perspective, all gas optimizations were evaluated by being applied locally and having the test suites ran to identify the median cost deltas via forge snapshot.

Given that gas-specific tests were only present for the Set implementation, the other gas-related optimizations should be re-evaluated once gas-specific tests have been introduced for the EthereumVaultConnector itself.

Security

The codebase does rely on indirect security checks at times that should be better documented, such as the invocation of EthereumVaultConnector::authenticateCaller in EthereumVaultConnector::setAccountOperator inferring that the EthereumVaultConnector::getAccountOwnerInternal function will yield a non-zero address.

We advise these implicit security checks to be properly documented, aiding future auditing endeavours in understanding the code's operation more efficiently.

The overall security of the EVC is inherently tied to the IVault implementations a particular account is attached to, and as such emphasis should be put in ensuring these implementations are adequately audited in the context of the EVC.

In this regard, we identified a potential issue in the way controller validations are performed which may be considered overly restrictive and thus result in an unhandled failure.

Vault Integrations

In addition to the above, we believe proper integration of the EVC is slightly complex and contains a lot of nuisances that may not be immediately apparent.

For example, the result of the EthereumVaultConnector::getCurrentOnBehalfOfAccount call should not be trusted if the top-level call was not initiated by the EVC itself as it may have been diverted by another contract.

Multiple similar security checks are expected to be implemented by IVault implementations but may not be immediately apparent by external developers.

To this end, we advise a comprehensive development guide to be produced that aids IVault developers in understanding the exact ramifications of each transient data point in the EVC as well as how to properly integrate each function within it.

Compilation

As a final note, the codebase is presently compiled with 0.8.24 whilst its pragma statements are unrestricted from 0.8.19 upwards.

As specified in the compilation chapter, we advise test suites to be run using multiple compiler versions to ensure no compilation discrepancies remain undetected in previous / future versions.

Overview Conclusion

We advise the Euler Finance team to closely evaluate all minor findings identified in the report and promptly remediate them as well as consider all optimizational exhibits identified in the report.

Post-Audit Conclusion

The Euler Finance team iterated through all findings within the report and provided us with a revised commit hash to evaluate all exhibits on.

We evaluated all alleviations performed by Euler Finance and have validated that all non-informational exhibits have been adequately dealt with.

In relation to the informational findings within the audit report, the following have been partially addressed and should be revisited: ECT-01C, EVR-05C

Post-Audit Conclusion (c943dcbbb6)

The Euler Finance team proceeded to fully address exhibit EVR-05C whilst acknowledging ECT-01C explicitly in a manner that aligns with best practices, rendering both exhibits fully addressed.

We consider all outputs of the audit report properly consumed by the Euler Finance team with no further actions expected, thus concluding this audit engagement.

Audit Synopsis

Severity	Identified	Alleviated	Partially Alleviated	Acknowledged
	0	0	0	0
	19	17	0	2
	3	3	0	0
	0	0	0	0
	0	0	0	0

During the audit, we filtered and validated a total of 1 findings utilizing static analysis tools as well as identified a total of 21 findings during the manual review of the codebase. We strongly recommend that any minor severity or higher findings are dealt with promptly prior to the project's launch as they can introduce potential misbehaviours of the system as well as exploits.

Total Alleviations

The list below covers each segment of the audit in depth and links to the respective chapter of the report:

• 🎯 Scope
• 💻 Compilation
• 🔍 Static Analysis
• 👁️ Manual Review
• 🖋️ Code Style