Beanstalk: The Finale

Summary

There is a potential security vulnerability when deploying Beanstalk migration contracts on the ZkSync chain. The ZkSync chain preserves the msg.sender for L1 -> L2 calls, which can lead to address impersonation issues if the same address on Ethereum and ZkSync is controlled
by different owners.

Vulnerability Details

The ZkSync chain preserves msg.sender during L1 -> L2 calls. This can lead to a situation where the same address on Ethereum and ZkSync is controlled by different entities, potentially leading to address impersonation attacks.

Example/Proof of Concept

For the ZkSync chain, the msg.sender is preserved for L1 -> L2 calls. In cross-chain strategies, it's critical not to assume that address control between L1 and L2 is always guaranteed.

For externally owned accounts (EOAs), it is generally true that any account accessible on Ethereum will also be accessible on other EVM-based chains. However, this is not always the case for contract-based accounts, as the same account or wallet address might be owned by different individuals on different chains.
This can occur if a smart contract wallet factory on multiple EVM-based chains deterministically deploys a wallet based on user-defined inputs.

For instance, if a smart contract wallet factory on both EVM-based chains uses deterministic CREATE2, which allows users to define its salt when deploying the wallet, Bob might use ABC as the salt on Ethereum, and Alice might use ABC as the salt on ZkSync. Consequently, both will end up with the same wallet address on two different chains. A similar issue occurred in the Optimism-Wintermute hack, but the actual incident was more complex.

Assume that 0xABC is a smart contract wallet owned and deployed by Alice on the ZkSync chain. Alice performs an L1 -> L2 cross-chain call from Ethereum to ZkSync with the delegate set to 0xABC address. Thus, on the destination chain (ZkSync), only Alice's smart contract wallet 0xABC is authorized to call functions protected by the onlyDelegate modifier.

Bob, an attacker, notices that the 0xABC address is not owned by anyone on Ethereum. Therefore, he interacts with the wallet factory to deploy a smart contract wallet with address 0xABC on Ethereum, effectively taking control of that address on Ethereum. Bob can now make L1 -> L2 requests impersonating Alice’s wallet 0xABC and bypass access controls on ZkSync that rely on msg.sender.

Additionally, Bob could make an L1 -> L2 request by calling ZkSync's BridgeFacet.xcall directly to steal Alice's approved funds. Since the xcall relies on msg.sender, it will assume that the caller is Alice.

This issue is specific to the ZkSync chain due to the preservation of msg.sender for L1 -> L2 calls. For other chains, the msg.sender is not preserved for L1 -> L2 calls and will always point to the L2's AMB forwarding the requests.

Impact

If an attacker can control the same address on Ethereum that is assumed to be owned by a user on ZkSync, they can access and manipulate assets and functions protected by the msg.sender check and steal or manipulate funds during the migration process.

Tools Used

Manual Review

Recommendations

To mitigate this risk, the following options are proposed.

Ensure that only externally owned accounts (EOAs) can call critical functions if deploying to ZK SYNC.
This could be achieved by adding a check in the contract functions to verify that tx.origin is equal to msg.sender.