Beanstalk: The Finale

Summary

The ReseedWhitelist contract lacks access control in its init function, allowing any user to call it and whitelist arbitrary tokens. This vulnerability could be exploited by an attacker to manipulate the Beanstalk protocol by adding malicious tokens to the Silo.

Vulnerability Details

The init function in the ReseedWhitelist contract does not have any access control, which means it can be called by anyone. This allows an attacker to whitelist any token, potentially leading to the addition of malicious tokens in the Silo. Here are the relevant code snippets:

ReseedWhitelist Contract

The init function is external and lacks any form of access control - such as LibDiamond.enforceIsOwnerOrContract() which is used in WhitelistFacet.whitelistToken() function. This allows any user to call the function and pass any tokens and asset parameters to the LibWhitelist.whitelistToken function. If we see how LibWhitelist.whitelistToken is implemented we will notice that it also don't have any access control in it.

Exploit Scenario

The problem could arise in the following way: Beanstalk's team migrates the project to L2, initializes tokens, and completes the setup. When they are ready to start the project on L2, a malicious actor calls the ReseedWhitelist.init() function with malicious tokens and gets them whitelisted. The attacker then deposits these tokens into the Silo and converts them for Beans or other assets. Because the init function lacks access control and does not have a restriction to be called only once, the transaction for whitelisting will succeed, allowing the malicious tokens to be whitelisted.

Impact

An attacker could whitelist a malicious token and exploit the Silo's mechanisms to manipulate the Beanstalk protocol, potentially leading to significant financial losses and disruption of the protocol's normal operations.

Tools Used

VSCode

Recommendations

Make the ReseedWhitelist.init() function callable only by the DAO and only once.