Beanstalk Native DEX (aka Liquidity Wells) Under Development is Susceptible to a Newly Identified Exploitable MEV Strategy that Results in the Theft of User Funds
BIC Response
Although this submission is related to Beanstalk assets that do not yet exist, the BIC has reviewed the submission in good faith and determined that the bug in question was only possible on Bunni due to the use of Uniswap V3 pools.
In Uniswap V3 pools, anyone is able to provide liquidity on behalf of another user by setting a recipient address at the time of deposit, which is unrelated to the current development direction of Wells. This is feature of Uniswap V3 is pointed out in the article that the hacker shared (https://www.rileyholterhus.com/writing/bunni):
"Calls mint on the underlying Uniswap V3 pool to mint $10,001 worth of liquidity to the Bunni protocol. In Uniswap V3, anyone can provide liquidity on your behalf by setting the recipient address."
This is not functionality that is being pursued in the development of Wells. Because of this, this report is not eligible for a reward.
Reporter Response
The general summary of the reported bug is that the first depositor (the attacker) to a new Liquidity Well pool could manipulate the price of a share to make other early user's deposits round down to zero, such that the attacker can then withdraw and steal all of the deposited tokens in the Liquidity Well pool.See the following two links noted at the end of the blog post from Riley Holterhus that was cited in the "References" section of the report:
https://code4rena.com/reports/2022-01-sherlock/#h-01-first-user-can-steal-everyone-elses-tokens
The reported bug is also not exclusive to a DEX employing Uniswap V3 functionality. Rather, the same problem could exist on a DEX following a constant product methodology akin to Uniswap V2 (as Liquidity Wells are expected to do), whereby liquidity providers will receive ERC-20 tokens to represent their share of a respective pool.
In the case of Uniswap V2, the reported bug is prevented by enforcing a minimal initial liquidity to new pools. See lines 120 and 121 from the Uniswap V2 code, which prevent the reported exploit by requiring a "MINIMUM_LIQUIDITY" be sent to the 0 address so it will stay there forever (10 ** 3, per line 15): https://github.com/Uniswap/v2-core/blob/master/contracts/UniswapV2Pair.sol
The rationale for this minimal initial liquidity requirement is further explained as follows: "If this is the first deposit, create MINIMUM_LIQUIDITY tokens and send them to address zero to lock them. They can never be redeemed, which means the pool will never be emptied completely (this saves us from division by zero in some places)." See: https://ethereum.org/en/developers/tutorials/uniswap-v2-annotated-code/
The justification for this minimal initial liquidity requirement to prevent the reported attack scenario is also explained here: https://ethereum.stackexchange.com/questions/132491/why-minimum-liquidity-is-used-in-dex-like-uniswap
Liquidity Wells should thus enforce a minimal initial liquidity requirement when being launched, to prevent this reported bug from occuring, per the "Recommendation" section of the report. Currently, in the Liquidity Wells facet that is under development, there appears to be no minimal initial liquidity sent to the 0 address. See lines 91 and after (under protocol/contracts/farm/facets/WellFacet.sol), where "Add Liquidty" (typo) is noted: https://github.com/BeanstalkFarms/Beanstalk/pull/83/files
As Liquidity Wells will be permissionless, enabling any Beanstalk user to launch new BEAN pools trading against other tokens, this precaution is especially critical. This is because the BEAN token contract, along with the Liquidity Wells facet once it debuts and is added as an update to the Beanstalk contract, will all be contained within the Beanstalk contract.
As mentioned in the "Impact" section of the report, the Beanstalk smart contract employs the EIP-2535 Diamond standard, enabling it to pull functions from a variety of facets housed within it, and all facets share the same state, thereby increasing the attack surface.
Lastly, in Beanstalk University Class #47, held in the Beanstalk discord on 10/18/22, Publius as one of the founders of Beanstalk mentioned with regards to the oracle development considerations around Liquidity Wells that they've recently come to learn that, "...someone has the potential to manipulate the balance within the [Liquidity] Wells for longer than a block..." This statement reaffirms the applicability of this reported bug report. See: https://www.youtube.com/watch?v=f5aQDshdttI&t=1847s
Ultimately, I have shared this report in good faith and hope that it is beneficial for Beanstalk's ongoing development efforts, and I would appreciate the BIC's reconsideration of its pertinence for Liquidity Wells as a substantive update to the Beanstalk contract that is expected in the coming months.
BIC Response
The implementation for Wells is not finished and the majority of it is going to be rewritten due to architectural changes. Because the implementation is not complete, it also necessarily not yet audited. The BIC deems it best practice to wait until the code is audited in order to consider any rewards. For these reasons, a bounty is not being awarded.
Immunefi Response
Our finding is that this submission don't have any impact of the selected asset. This submission was correctly closed and no reward should be given.TECHNICAL ASSESSMENT:
Here are some more specifics from our technical assessment of the mediation request. The asset that you've pointed out,
Liquidity Wellsis out-of-scope as it is still under development process and any bugs at this stage of development are understandable since it wasn't yet audited. Besides, the project may change this asset and it will not affect the end user, therefore there is no impact.You've also mentioned, that:
The argument that "further updates to the contracts" do not qualify as in-scope unless a BIP is committed is simply disingenuous.
further updates to the contractsmeans that Beanstalk's contract was already updated, meaning it is useable by the user and can be accessed through the beanstalk diamond proxy. The assetLiquidity Wellswas still under development, therefore hasn't been updated to the beanstalk contract and as a result is out-of-scope.On top of that, the mentioned asset is still in an open PR and hasn't got merged to the master branch https://github.com/BeanstalkFarms/Beanstalk/pull/83/files.