Beanstalk: The Finale

Summary

The identified vulnerability in the Beanstalk protocol's FieldFacet allows a malicious actor to manipulate the Pod line by performing numerous small sow transactions. This results in an inflated queue(Pod Line), pushing legitimate sowers further back in the line and delaying their ability to harvest Pods.

Vulnerability Details

The Beanstalk protocol allows users to sow Beans in exchange for Pods. Newly issued Pods accumulate in the back of the Pod Line. This vulnerability arises because the protocol does not enforce a minimum amount of Beans required for sowing. This oversight allows an attacker to perform a large number of sow transactions with very small amounts of Beans, each creating a new plot in the Pod line. As a result, the Pod line becomes filled with these tiny plots, pushing legitimate users' plots further back in the line and significantly delaying their harvest.

I have written the following PoC test to demonstrate that there is no minimum required amount for sowing and that the attacker will be able to artificially increase the Pod Line size.

Steps to reproduce the PoC:

1. Copy paste the test_maliciousSowerIncreasesQueueSize in Field.t.sol

2. Import "forge-std/Test.sol" in Field.t.sol and LibDibbler.sol as we'll use console.log from it

3. Put the needed console logs in LibDibbler.sol (see below)

4. Command for running the test forge test --mt test_maliciousSowerIncreasesQueueSize -vv

I also added the following console.log statements in LibDibbler.sol's sow() function to show how the Pod Line size increases. A legitimate user's sow index becomes 800, although it could be much lower (e.g., second index or at least it could be in top 10).

Impact

By flooding the Field with small amount sows, an attacker can make the incentives for other participants significantly less attractive. Their plots will become harvestable much further in the future, effectively discouraging users from participating in the Field. Since the Field is a critical component for adjusting the Bean value towards its peg, reduced user participation could result in destabilization of the Bean price and the protocol itself.

Tools used

VSCode, Foundry

Recommendations

To overcome this issue, one of the following approaches could be implemented:

1. Minimum Sowing Amount + Cooldown Periods: Implement a minimum amount of Beans required for sowing. This would prevent attackers from creating an excessive number of plots with tiny amounts of Beans. Also introduce a cooldown period between sow actions for the same address. This would limit the ability of an attacker to flood the system with sow transactions in a short period.

2. Priority Mechanism: Implement a priority mechanism that gives preference to larger sow amounts. This could be achieved by weighting the plot positions based on the amount of Beans sown.