As part of Aave’s focus on security and transparency, the Aave Genesis team will be periodically releasing a report centred on the security of the Aave Protocol and all the other systems of the Aave ecosystem.

Aave Governance v2

ARC (Aave Request for Comments)

After the release of the Aave Protocol v2 last week, the upgrade of the Aave Governance from v1 to v2 has been submitted to the community for discussion.

More details about the proposal can be found in the governance forum, but in terms of security, there are certain aspects to highlight:

1. As with any other software system, some parts of the infrastructure are critical. The Aave governance has the objective of controlling all the different parts of the ecosystem, and taking into account the aforementioned, permissions over contracts are split between 2 different smart contracts, with different configurations. The first (Executor with long timelock) has control over pieces with low frequency of interaction, like the AAVE governance token or the StkAAVE of the Safety Module. The second (Executor with short timelock) has control over pieces with higher frequency of interaction, like the Aave Protocol v1 and v2. Having a longer timelock on changes concerning tokens, and in general longer time-configurations is usually a good practice security-wise, as it leads to longer reaction window for any external party integrating the tokens.

2. The design goals of this Governance V2 were simplicity, by following industry standard practices; and innovation, by introducing delegation of proposition power in both the AAVE and StkAAVE.

3. There is a guardian role with permissions to cancel proposals in order to have a safe-guard against malicious ones. This role will be on a multi-signature wallet with 5-of-10 signatures needed.

4. All of the changes proposed have been audited by industry security leaders and usual collaborators of AAVE, in this case PeckShield and Certora.

If the community considers it appropriate, the next steps will be the deployment of the necessary smart contracts in the Ethereum main network, and the creation of the proposal on the Aave Governance v1 to proceed with the upgrade to v2.

Aave Protocol V2

One week has passed since the release of the Aave Protocol v2, and we are proud that there haven’t been any incidents. However, the following potential attack vector has been discovered and fixed during these first days.

On Friday, 4 December 2020, 19:18 UTC, the Aave team received a notification from the security researcher Josselin Feist from Trail of Bits reporting the following issue:

There was a possible attack vector in the Aave Protocol v2 that had the potential to cause a smart contracts Denial-of-Service attack on the protocol that could impact the state of the protocol, other protocols integrating Aave and users. The vulnerability is the following:

The implementation contract of the LendingPool proxy was not correctly initialized at that moment, and because of a connection with another LendingPoolCollateralManager contract, via DELEGATECALL, it would be possible for an attacker to provoke a selfdestruction of the implementation logic, leaving the system temporarily not operative until a new implementation is set.

Even if this doesn’t involve any loss of funds, which is the most critical scenario in a protocol like Aave, the potential consequences are considered high according to our standards.

As it can be seen here, the LendingPool contract uses a DELEGATECALL proxy pattern, meaning that users interact with the proxy, while the code executed is on the implementation.

Proxy pattern used on Aave

This implementation contract contains an initialize function, which sets the addresses provider address (_addressesProvider here), and can only be called if the initializer function modifier does not revert. The conditions are:

conditions to call the initialize function

On the running system on Friday, even if everything was correctly configured on the proxy contract, it was not the same case on the logic contract itself:

• revision on the implementation was 2
• lastInitializedRevision was 0

So, the require was passed and anyone could call on the LendingPool implementation initialize and set the _addressesProvider on the storage of the implementation contract. This malicious contract would return a LendingPoolCollateralManager address from _addressesProvider.getLendingPoolCollateralManager() containing also malicious code.

After that, the attacker would call the liquidationCall function on the LendingPool implementation. As the state here is completely different to the one in the proxy (the real state of the system), nothing on the protocol can be affected, but if the liquidationCall function in the malicious returned LendingPoolCollateralManager does a selfdestruct, this will destroy the LendingPool implementation contract, as a DELEGATECALL is used.

The DELEGATECALL that would cause the self-destruct

Initially, it could appear that when a proxy contract calls as implementation an address without code (remember that the code was self-destructed in the previous step), the transaction would just revert. But this is not actually the case on the used OpenZeppelin proxy contract, as the proxy lacks an existence check on its fallback function. This means that if the proxy does a DELEGATECALL on an implementation address with no code, the proxy will return success, but no actual code is executed. And this is where the Denial-of-Service appears: anybody calling the LendingPool legitimately would have his transaction succeeded, but without any state change in the protocol.

As soon as the Aave team received the report from Josselin, we suspected that due to the “obscure” nature of the vulnerability, it could also probably affect v1 of the protocol. Also, we knew that the solution would be easy and fast to execute, just by calling the initialize function in the LendingPool of both protocols with the correct/current _addressesProvider, blocking any further attack opportunity.

We also immediately realised that, even if we use the proxy pattern extensively, the only vulnerable place was the Aave Protocol itself, because the attack vector only appears in presence of a DELEGATECALL to another contract.

A high-level recap of our steps were:

• 7:18 PM UTC The team receives the vulnerability report from Josselin, immediately 3 members of the Aave team initiate the internal discussion involving Josselin on the next steps
• 7:34 PM UTC We call initialize in the v1 LendingPool, the most critical system https://etherscan.io/tx/0x98089120cd9b1a83a8c5233f6773ff9c12b7451a12532b7ef103d0a85419aa4e
• 7:53 PM UTC We call initialize in the v2 LendingPool, https://etherscan.io/tx/0x5e7b4c263d3f764583bd9fbd39bd7276295f033bf42bbcd97bc0e4d8f7d22ed2
• 8:13 PM UTC We call initialize in the v1 Uniswap LendingPool https://etherscan.io/tx/0x714d19c1057de00921836a9edbb24319f3ff64e4499bf80c6f86bdf57cbe852b

With all the main systems fully protected, we deeply reviewed all of our other contracts deployed in main, but as for our initial thoughts, nothing was affected.

Consequences of a hypothetical attack

As previously described, the attack would be a Denial-of-Service involving Ethereum smart contracts, and because of their particular nature, the criticality is usually higher than in a “traditional” DoS.
Taking into account the reaction time of the Aave team, a hypothetical attack would have a margin of time to generate profit/damage in a range of minutes/hours, and could be as following:

• The attacker executes the exploit on both v1 and v2 LendingPool contracts.
• At this point, the points of further exploit are:
• Just stopping the service of the protocol, creating some loss of state affecting all users interacting with during the attack timeframe, that later on would need to be reconstructed from the inputs.
  - Temporary block ETH funds of users doing new deposits() in the LendingPool, as the ETH would be transferred and the deposit() function would still succeed. The balance of these users would need to be modified according to their deposits later on.
  - Block all the extraction of funds from the protocol, as no code would allow for transfers out.
  - In the case of Aave v2, due to the usage of a WETHGateway contract to allow people holding ETH to deposit WETH, an attack vector could appear stealing funds of users trying to deposit WETH during the attack time frame.
  - More sophisticated exploits based on platforms integrated with Aave, dependant on their particular implementation.

With a carefully designed plan, potentially involving some kind of social engineering, it can’t be discarded that some users could have loss of funds if the attacker realised the WETHGateway attack vector, which involves quite a deep understanding of the system. The rest of the problems, even if tedious to fix, would have a solution.