Beanstalk Notion
Beanstalk Notion
📄

Report #21241

Report Date
June 9, 2023
Status
Closed
Payout

It's possible to manipulate the `deltaB` of the following season

‣
Report Info

Report ID

#21241

Target

https://etherscan.io/address/0xC1E088fC1323b20BCBee9bd1B9fC9546db5624C5

Report type

Smart Contract

Impacts

Illegitimate minting of protocol native assets

Has PoC?

Yes

Bug Description

The function gm() calculates the deltaB of the new season based on the CURRENT balances of the 3CVR/BEAN metapool.

Because of this an attacker can manipulate the deltaB of the following season by:

  1. Adding liquidity, removing liquidity or swapping assets within the metapool
  2. Calling gm() while the metapool balances are manipulated
  3. Perform the inverse of the operation of .1 to get the pool back to normal state and his liquidity back

Impact

The deltaB is a core mechanic of Beanstalk that allows BEAN to keep the peg, being able to manipulate it breaks all the assumptions about how the protocol works.

At the current state BEAN is below the peg, the protocol should try to attract USDC/DAI/USDT/3CVR LP to re-peg the asset, but an attacker can force the protocol to mint BEANS which will further de-peg the asset if the BEAN receivers decide to swap BEANS for 3CVR in the metapool.

As an example the current deltaB is negative and an attacker can force it to be positive in the next season which will have the protocol mint and distribute BEANS to:

  • Current stalkholders
  • Active fertilizer holders
  • The first pods in the FIFO line

Risk Breakdown

The maximum amount of BEANS that it's possible to force the protocol to illegitimately mint is 1% of the current supply, and it's possible to do this once per season. At the current state is possible to force the protocol to mint a maximum of ~350.000 BEANS for a value of ~315.000$ with a manipulation cost of ~2950$.

The attack can be profitable for the attacker if:

  • Owns a percentage of stalk that allows him to receive an amount of BEANS high enough to cover the attack costs
  • Owns a percentage of active fertilizer that allows him to receive an amount of BEANS high enough to cover the attack costs
  • Owns the first ~3000 pods in the FIFO line, because BEANS will be minted directly to him

In the worst-case scenario of an attacker owning the first ~100.000 pods in the FIFO line, which he might be able to buy in the market, he would be able to steal ~100.000$ (1/3 of ~315.000$) right now.

Besides minting and de-pegging BEAN manipulating the deltaB can be used to:

  • Manipulate the temperature
  • Manipulate the soil supply
  • Force raining or flood if the pod rate is low enough

Recommendation

The function updateOracle() which is called by gm(), should use the previous balances of the metapool to calculate deltaB, like it's done in the function bdv() in the LibBeanMetaCurve library.

Other

I'm disclosing this as critical even if the impact I selected is listed as high because I can only select one impact, but the impacts possible are:

  • Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
  • Illegitimate minting of protocol native assets
  • Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)

I believe it to be a protocol-breaking bug, and in some scenarios (attacker owning enough stalk/fertilizer and/or the first pods in line) it can be used to profit and steal 3CVR from the metapool.

Proof of concept

I provide a runnable POC written using forge in a GitHub private repo, once I know the Github username of the collaborator(s) to add.

The POC proves it's possible to manipulate deltaB and force the protocol to mint beans, showing the amount of BEANS minted, the value of the BEANS minted and the cost of the attack. It shows 2 ways of doing so:

  • testLiquidity(): manipulates deltaB by adding 3CVR liquidity to the metapool
  • testSwap(): manipulates deltaB by swapping 3CVR for BEANs in the metapool

BIC Response

This is not a valid bug report because the number of Beans that Beanstalk mints upon the call of the gm function is based on the time-weighted (and liquidity-weighted) deltaB over the previous Season, not the instantaneous deltaB. This significantly reduces the magnitude of manipulation possible. The 1% minting cap minimizes the magnitude of any multi-block MEV manipulation (see https://bean.money/ebip-2)

Due to these reasons, we are closing the submission and no reward will be issued.