Ondo Finance - pep7siup's results

Lines of code

https://github.com/code-423n4/2023-09-ondo/blob/main/contracts/bridge/DestinationBridge.sol#L108

Vulnerability details

Impact

The DestinationBridge._execute's payload is only constructed based on VERSION, sender, amount and nonce which does not quarantee uniqueness between different source chains. This could cause transaction hash colissions. Given the srcSender is a big integrated protocol, the chances of nonce collision are very likely. When txnHash colides, txnToThresholdSet & txnHashToTransaction data from the pending tx would be silently overriden at lines 109-110.

// Findings are labeled with '<= FOUND'
// File: contracts/bridge/DestinationBridge.sol
85:  function _execute(
86:    ...
108:    bytes32 txnHash = keccak256(payload);// <= FOUND
109:    txnHashToTransaction[txnHash] = Transaction(srcSender, amt);
110:    _attachThreshold(amt, txnHash, srcChain);
111:    _approve(txnHash);
112:    _mintIfThresholdMet(txnHash);
113:    ...
114:  }

As only one of the identical transactions would be successfully processed in _mintIfThresholdMet, and the other is overridden due to the collision of transaction hashes, the result is a loss of funds for the sender.

Potential loss = ( number of identical transactions - 1 ) x amount

Proof of Concept

1. Scenario Setup: Suppose there are two source chains, Chain A and Chain B, and a protocol P that wants to send $1000 worth of tokens from Chain A to Chain B using a function burnAndCallAxelar with nonce = n.

2. Chain B Execution: Axelar executes a corresponding transaction on Chain B in response to the burnAndCallAxelar function call. The transaction data is registered with a unique transaction hash txnHash.

3. Pending Transaction: While the transaction on Chain B is still pending and awaiting enough approvals, protocol P performs operations on Chain C, catching up from nonce = n - m to the current nonce = n. During this time, protocol P sends another burnAndCallAxelar transaction with the same payload to Chain B.

4. Override Transaction Data: Axelar repeats the process for the new transaction on Chain B, overriding the previously registered data associated with the same txnHash.

5. Execution on Chain B: Eventually, enough approvals are met for the transaction on Chain B. As a result, tokens worth $1000 are minted on Chain B based on the overridden data. However, this action disregards the other $1000 worth of tokens that were part of the original transaction on Chain A.

6. Loss of Funds: The result is a loss of funds, as only one of the two identical transactions is successfully processed, and the other is overridden due to the collision of transaction hashes.

Tools Used

Manual Review

Recommended Mitigation Steps

To mitigate this issue, it is recommended to include the source chain name in the transaction hash calculation, making it unique throughout multiple chains. This way, collisions between transaction hashes from different source chains can be prevented, ensuring that all cross-chain transactions are reliably processed.

Assessed type

Other