Summary

The usage of certain function via tractor blueprints can give the executor of the blueprint complete control of the publisher's position in the protocol

Relevant GitHub Links:

https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/main/protocol/contracts/libraries/Token/LibEth.sol#L18
https://github.com/Cyfrin/2024-05-beanstalk-the-finale/blob/main/protocol/contracts/beanstalk/farm/TractorFacet.sol#L46-L61

Vulnerability Details

The tractor component is meant to execute operations inside the Beanstalk protocol on behalf of a publisher. That means that a user can ONLY execute those functions that the publisher exclusively allowed him to execute. This feature should not enable someone to execute any arbitrary function. However, there are specific functions that can enable a user to execute any arbitrary function on the protocol on behalf of the publisher that he has not allowed to execute.
These function have a particularity, return eth to the caller. Specifically executes the refundEth function:

This function basically tries to send the remaning ETH in the Beanstalk contract to the msg.sender. When the contract sends ETH to the caller it will pass the transaction execution to the msg.sender.
The main problem here is that when someone is executing one of the functions that refunds ETH on behalf of a publisher, he will gain the transaction execution and will have the hability to call any arbitrary function inside the Beanstalk contract on behalf of the publisher without being allowed to. That's because the activePublisher will expire once all the functions that the publisher allowed to execute ends. So if the ETH refund is executed in the middle of one of these transactions, the attacker will have the activePublisher set to the victim and the transaction execution to call any arbitrary funcion on behalf of the publisher.

The list of functions that make this exploit possible are:

Proof of concept:
In this Proof of Concept I created a function to fetch the active publisher and did not executed any attack to Alice, just demonstrated that Bob got the transaction execution where he can execute any arbitrary function on behalf of Alice.
This test uses the Field.t.sol setup:

Traces:

As we can see, when the GetPublisher event is emitted, the address matches with the Alice's one. That means that any function called inside the Beanstalk protocol will be done on behalf of Alice.

Impact

High, if a publisher signs a hash to execute any of the previously mentioned functions, any user can execute any arbitrary function on his behalf. That includes transfering all tokens out of the publisher's balance, transfer fertilizer, transfer pods, etc...
There are just a few functions that allow this attack but if someone makes a blueprint executing any of these, can get all his positions drained by any malicious actor because it can be called by everyone.

Tools Used

Manual review

Recommendations

From my point of view the best mitigations would be:

1- Set s.sys.isFarm = 2. This way the refundEth function would not give the transaction execution to the caller.

2- Refund the Eth to the active publisher instead of the msg.sender by changing this:

3- Add the nonReentrant modifier in each of the previously mentioned functions