The Euler Labs team recently deployed a preventative update to the Euler smart contracts that protects contracts integrating with Euler against a class of manipulation attacks. As far as we know, no users were ever exploited by this issue, but it is quite an interesting attack vector and very likely applies to other projects as well.

Background

Like many other DeFi systems, Euler created a wrapper asset around deposited tokens. For example, eDAI is a wrapper for DAI. Since this is an interest-earning asset, each unit is redeemable for a growing amount of DAI. At any given point in time, the amount of DAI a user can receive for a unit of eDAI is given by the “exchange rate”. This value is computed by dividing the pool’s assets (balance plus outstanding borrows) by the total outstanding eToken balances. Protocols that integrate with Euler may use the exchange rate to compute the underlying value of an eToken deposit by calling convertBalanceToUnderlying() on an eToken.

On July 25th, Sherlock notified the Euler Labs team about a bug bounty submission they received for their staking system, which uses Euler. It was a sophisticated attack that relied on the interactions between three separate protocols: Euler, Sherlock’s staking system, and the 1inch DEX aggregator.

The bug bounty detailed that the swap module allowed a user to exchange one eToken for another using either Uniswap or 1inch. However, with 1inch, the swap data was treated as a black box by the Euler contracts, and the 1inch router allowed the invocation of arbitrary contracts (including attacker created ones). Fortunately, the Euler system used a reentrancy guard that prevented re-entering into Euler at that time.

Unfortunately, during the 1inch execution, after a swap was performed the funds would have been moved into the Euler contract but have not yet been credited to the total balances, and in fact cannot have been because it did not know the precise amount that would be returned from 1inch. This meant that at this point calling convertBalanceToUnderlying() would return an incorrect value. An attacker could have invoked a victim contract, such as Sherlock’s staking contract, and it would have used an incorrect exchange rate for its computations.

Another way of describing this is that Swaps were not atomic operations in Euler: They consisted of underlying token transfers, followed by updates to EToken balances. Critically, due to the 1inch router’s flexibility, an attacker could have run code in between those two operations.

Mitigation

The Euler Labs team together with Sherlock discussed several ways of fixing this issue. Simply removing 1inch swapping support altogether was considered, but this is undesirable because Euler users can often receive better prices and execution from 1inch. Additionally, there may be other opportunities for attackers to run arbitrary code at times when Euler’s internal data was in an inconsistent state, so this was not a comprehensive solution.

Improving the atomicity of the swapping operation, or sanitising the 1inch “black box” swap data prior to a swap were other options, but these were brittle and still not comprehensive fixes.

The option selected was to add what we are calling a read-only re-entrancy guard. This works by having convertBalanceToUnderlying() (and all other methods that use the internal loadAssetCacheRO utility) verify that the re-entrancy guard has not been locked. If it has, then an error is thrown. Typical integrations will propagate this error and revert, preventing an attacker from taking advantage of inconsistent exchange rates.

On Aug 4th, this fix was deployed, which transparently fixed the issue for all existing and future Euler integrations.

While this was technically a breaking change, existing integrations were analysed and future users were considered before determining that this restriction would not cause any significant issues for legitimate users. Instead, this provided a comprehensive solution to the attack identified in Sherlock’s bug bounty, as well as any future cases where users are able to execute arbitrary code during the execution of an Euler operation.

Thanks

Euler Labs would like to thank the Sherlock team, who brought this issue to attention and collaborated on designing and deploying the mitigation described above.

The Labs team would also like to thank the teams behind the various other Euler integrations for acting promptly and professionally to ensure no users’ funds were at risk.

About Euler

Euler is a capital-efficient permissionless lending protocol that helps users to earn interest on their crypto assets or hedge against volatile markets without the need for a trusted third-party. Euler features a number of innovations not seen before in DeFi, including permissionless lending markets, reactive interest rates, protected collateral, MEV-resistant liquidations, multi-collateral stability pools, sub-accounts, risk-adjusted loans, and much more. For more information, visit euler.finance.

Join the Community

Follow Euler on Twitter. Join the Discord. Keep in touch on Telegram (community, announcements). Check out the website.