TempleGold

Summary

The TempleGold::send function does not support Account Abstraction, which leads to potential issues when users have addresses on multiple chains. The function's current design prevents cross-chain transfers to the same user's address on different chains due to a strict sender-receiver check. Additionally, this mechanism does not effectively restrict transfers only to the user's own addresses and can result in unauthorized transfers between contracts.

Vulnerability Details

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGold.sol#L290

https://github.com/Cyfrin/2024-07-templegold/blob/57a3e597e9199f9e9e0c26aab2123332eb19cc28/protocol/contracts/templegold/TempleGold.sol#L218-L222

The vulnerability arises from the following code snippet in the TempleGold::send function:

This check ensures that the sender (msg.sender) must be the same as the receiver (_to). However, in scenarios where users have different addresses on different chains, this check will cause the transaction to revert, preventing legitimate cross-chain transfers.

Moreover, the assumption that this check restricts transfers only to the user's own addresses is flawed. It fails to consider cases where the holder of an address on one chain may be a different entity on another chain. This leads to potential security risks with wallets supporting Account Abstraction.

When _from and _to addresses differ for wallets supporting Account Abstraction, the TempleGold::_update function allows transfers between authorized and unauthorized contracts, leading to unauthorized token transfers.

Proof of Concept (PoC)

1. PoC #1:

   • Contract A is authorized.

   • Contract B is unauthorized.

   • Contract B transfers tokens to Contract A.

   • Result: Transfer is successful despite Contract B not being authorized, and tokens end up in an authorized contract.

2. PoC #2:

   • Contract A is unauthorized.

   • Contract B is authorized.

   • Contract B transfers tokens to Contract A.

   • Result: Transfer is successful despite Contract A not being authorized, and tokens end up in an unauthorized contract.

Impact

This vulnerability can lead to unauthorized transfers of tokens between contracts, undermining the security of the protocol. Users will be unable to perform legitimate cross-chain transfers to their own addresses, which affects the usability and reliability of the TempleGold::send function.

Tools Used

Manual Review

Recommendations

1. Revise the TempleGold::send function to support Account Abstraction by enabling legitimate cross-chain transfers to the user's own addresses.

2. Implement additional checks to ensure that only authorized transfers are allowed between contracts, preventing unauthorized token movements when using the send function.

3. Conduct comprehensive testing to verify the correctness and security of the updated implementation.