Loss of token if a smart contract perform a cross-chain transfer using source bridge

[c4-submissions]

Lines of code

https://github.com/code-423n4/2023-09-ondo/blob/47d34d6d4a5303af5f46e907ac2292e6a7745f6c/contracts/bridge/SourceBridge.sol#L61
https://github.com/code-423n4/2023-09-ondo/blob/47d34d6d4a5303af5f46e907ac2292e6a7745f6c/contracts/bridge/DestinationBridge.sol#L90

Vulnerability details

Impact

Loss of a token ownership if a smart contract perform a cross-chain transfer using source bridge

Proof of Concept

When a caller call burnAndCallAxelar, the token is burnt on source chain

and the payload is encoded in this way:

bytes memory payload = abi.encode(VERSION, msg.sender, amount, nonce++);

when on the dest chain triggers _execute,

(bytes32 version, address srcSender, uint256 amt, uint256 nonce) = abi
  .decode(payload, (bytes32, address, uint256, uint256));

and the token is minted to srcSender, which is the same address from the source chain

but the issue is, if a smart contract call burnAndCallAxelar on source chain, the owner of the smart contract may not belong to the original caller in dest chain

in that case, the token ownership is lost

for example https://rekt.news/wintermute-rekt/

the false assumption of a mutlisig smart contract address is controlled by same owner in different network has cost 20M OP lost

Tools Used

Manual Review

Recommended Mitigation Steps

let user specify a recipient address in the source bridge when calling burnAndCallAxelar

then the recipient on dest bridge receives the minted token

Assessed type

Token-Transfer

[c4-pre-sort]

raymondfam marked the issue as duplicate of #119

[c4-pre-sort]

raymondfam marked the issue as sufficient quality report

[c4-judge]

kirk-baird marked the issue as duplicate of #406

[c4-judge]

kirk-baird marked the issue as satisfactory