✅Community Workshop: Riley Holterhus

Intro

This workshop covers ERC4626 inflation attack.

Video:

Community Workshop: Riley Holterhus

Slides:

portfolio/Spearbit_Maple_Workshop.pdf at master · spearbit/portfolioGitHub

Spearbit_Maple_Workshop.pdf

ERC4626 Inflation Attack

Description

This is the inflation attack I mentioned.

The contract implements basic ERC4626 operations. Users can deposit WETH to get vault shares, and they can burn vault shares to get WETH back, plus interest.

The bug is in the deposit() function:

function deposit(uint256 assets, address receiver) external {
    uint256 sharesToMint;
    if (totalSupply == 0) {
        sharesToMint = assets;
    } else {
        
    }
    require(sharesToMint != uint256(0));
    
    depositToken.transferFrom(msg.sender, address(this), assets);

    _mint(receiver, sharesToMint);
}

The sharesToMint math can go wrong. Recall that integer division in Solidity rounds down. This rounding issue leads to inflation attack against the first victim depositor.

PoC

Here is a table summarizing the attacking steps:

Inflation attack

Basically, attacker deposits 1 wei to mint 1 share in a newly-created vault.

Then, the attacker transfers 100 WETH directly to the contract without using the deposit() function. This step is done by transfer() or transferFrom(). The attacker is losing money here to inflate the vault. Now the totalSupply is still 1 share but balanceOf becomes a huge number 1 + 100 * 10**18.

When the first victim depositor deposits, say, 200 WETH, the computation for sharesToMint goes wrong. The formula is:

(assets * totalSupply) / depositToken.balanceOf(address(this))

Substitute in:

sharesToMint = ((200 * 10**18) * (1)) / (1 + 100 * 10**18)
                     |            |              |
                assets: 200 WETH  |          balanceOf
                             totalSupply

sharesToMint = floor(1.9999...) <- Integer division in Solidity rounds down
sharesToMint = 1           <- This is really bad: 1.99 shares become 1 share

We see the victim lost 0.9999... share in this deposit. Now attacker owns 1 share and victim owns 1 share, so they evenly own all the money in the vault.

In the end, attacker withdraws 1 share. How much can the attacker profit:

Attacker's cost = 100 WETH + 1 wei, let's just say the cost is 100 WETH.
The vault balance is 300 WETH + 1 wei, let's say the balance is 300 WETH.
There are 2 shares, so 1 share = 150 WETH.
Attacker's profit = 150 WETH - 100 WETH = 50 WETH.

This bug exists in other protocols

• UniswapV2

  • LP tokens instead of vault shares

• Bunni by Timeless Finance

  • Manually supply liquidity instead of manual transfer of tokens

• xSushi-like contracts

  • Pretty similar, and you can see a first deposit of $60M USD 🤯

How to fix this bug?

The solution mentioned in the workshop is minting some of the initial amount to the zero address. This makes the "rounded down" shares less dominate in the computation.

I would suggest using a "multiplier" just like what is used for computing floating point numbers. Suppose the multiplier is 6, then 1.9999.. shares -> 1999999.999... shares. The "rounded down" part becomes less important.