Beanstalk: The Finale

Summary

Meet in the middle attack due to hash collision causing draining of native assets such as Bean/Unripe Bean /unripe Bean LP and basin tokens
An EIP 3607 which rationale is this exact attack. The EIP is in final state.

The blog post showcasing the cost of executing the attack

The hashrate of the BTC network has reached hashes per second as of time of writing, taking only just 31 minutes to achieve hashes. A fraction of this computing power will still easily find a collision in a reasonably short timeline.

Vulnerability Details

The ReseadBean.init() function is used to deploy lightweight proxy contracts for the user using CREATE2. We show that a meet-in-the-middle attack at finding an address collision against an undeployed account is possible. Furthermore, such an attack allows drainning the native assets[bean/unripe bean/unripe bean LP] from the respective contracts.

The address collision an attacker will need to find are:

One undeployed Beanstalk address (1).
Arbitrary attacker-controlled wallet contract (2).
Both sets of addresses can be brute-force searched because:

As seen, salt is a user-supplied parameter. By brute-forcing many salt values, we can obtain many different (undeployed) wallet accounts for (1).
(2) can be searched the same way. The contract just has to be deployed using CREATE2, and the salt is in the attacker's control by definition.
An attacker can find any single address collision between (1) and (2) with high probability of success using the following meet-in-the-middle technique, a classic brute-force-based attack in cryptography:

Brute-force a sufficient number of values of salt (2^80), pre-compute the resulting account addresses, and efficiently store them e.g. in a Bloom filter data structure.
Brute-force contract pre-computation to find a collision with any address within the stored set in step 1.

Impact

Address collision can cause all assets to be drained

Tools Used

Manual Review

Recommendations

Don't allow the user to control the salt used.
Consider also adding and encoding block.timestamp and block.number combined with the user's salt. Then the attacker, after they successfully found a hash collision, already has to execute the attack at a fixed block and probably conspire with the sequencer to ensure that also the time is fixed.