Omniscia Euler Finance Audit
Ethereum Vault Connector Security Audit
Audit Report Revisions
Commit Hash | Date | Audit Report Hash |
---|---|---|
69626eba20 | March 27th 2024 | a9eee03d03 |
577d1991de | April 7th 2024 | 189f419915 |
577d1991de | April 7th 2024 | 7b5998275f |
c943dcbbb6 | May 3rd 2024 | 33f824c042 |
c943dcbbb6 | May 16th 2024 | 62b5bb09c6 |
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: