Summary

Transferring TGLD cross-chain exposes users to potential token theft due to the wrong assumption that they control the same address on multiple EVM-compatible chains. This vulnerability, similar to the Wintermute incident, can result in attackers controlling the destination address and stealing the TGLD tokens from honest users.

Vulnerability Details

First from the contest's readme we can see that protocol is to be deployed on any EVM compatible chain, i.e https://github.com/Cyfrin/2024-07-templegold/blob/a47602635bf55221404fc9ceb96a8bb6c0db36a2/README.md#L156-L158

Now, from the temple gold readMe we can see that the below code/road path has been hinted for the transfers of the TGLD token https://github.com/Cyfrin/2024-07-templegold/blob/a47602635bf55221404fc9ceb96a8bb6c0db36a2/protocol/contracts/templegold/README.md#L11-L12

This however would mean that some users would lose their tokens cause protocol have claimed to them that they own the same address on multiple EVM chains, which would not be the case for all users.

Note that this bug case is very similar to the Wintermute case from two summers back, where 20 million worth of OP tokens were lost ~$27.6M as at the time of the incident... source.

As explained in the rekt article tagged above, it is possible to gain control of the same address for contract accounts in a different chain, especially for those contract accounts that are deployed using the Gnosis Safe contracts:

So in the case the _address hardcoded (sender) _to receive the tokens on the other chain (any EVM compatible chain) is not controlled by the same sender of the tokens this means that the users tokens is effectively lost.

See how the send is being finalised https://github.com/Cyfrin/2024-07-templegold/blob/a47602635bf55221404fc9ceb96a8bb6c0db36a2/protocol/contracts/templegold/TempleGold.sol#L281-L311

As hinted by the @audit tag, users can only end up transferring their tokens cross-chain to the same address so to go into more details as to how the bug case would actualise, suppose that a user uses a MultiSigWallet contract to teleport their TGLD tokens, in the TempleGold contract, the address of the MultisigWallet will be used and all the TGLD that were bridged will be deposited to this MultiSigWallet on the receiving chain effectively having the real user lose out on their funds and the attacker stealing unearned TGLD tokens.

Now, the problem is that the address of the MultisigWallet, might not be controlled by the same user on a different chain, as has happened in the past and as explained by this article from rekt: https://rekt.news/wintermute-rekt. So for example, in Polygon, an attacker could gain control of the address of the same address of the MultisigWallet that was used to teleport the tokens from the original chain. So the attacker having gained control of this address, i.e the MultisigWallet that deposited tokens from the original chain in the Polygon Branch having them take control of the funds.

Impact

As hinted under Vulnerability Details, since users are given the assumption that they always own the same address on the receiving chain where they want to cross-chain their tokens to, then this could lead to them effectively losing their TGLD tokens, since they don't have access to this address on the receiving chain, and the likelihood of this bug case is quite higher than expected, considering Temple has plans in place to be deployed on any EVM compatible chain as hinted in the readMe/docs.

Tools Used

• Manual review

• Wintermute incident

• Past finding.

Recommendations

Consider integration a receiving address when the cross chain is to occur and remove the enforcal that the to is not exactly the same as the msg,sender calling the function, i.e
https://github.com/Cyfrin/2024-07-templegold/blob/a47602635bf55221404fc9ceb96a8bb6c0db36a2/protocol/contracts/templegold/TempleGold.sol#L281-L301