Submitted by rbserver, also found by rbserver, jasonxiale, avoloder, Moksha, Coinymous, 0xNirix, SBSecurity, Respx, Emmanuel, said, haxatron, Shaheen, mojito_auditor, fyamf, klau5, ZdravkoHr, ABAIKUNANBAEV (1, 2), and Rhaydden
Because the ChakraSettlement.receive_cross_chain_msg function does not ensure that the receiving ChakraSettlement contracts contract_chain_name must match the to_chain corresponding to its txid input, the signatures that should only be used for calling the ChakraSettlement.receive_cross_chain_msg function on to_chain A can also be allowed to be used on to_chain B. As a result, the handler on to_chain B can incorrectly mint or transfer tokens to recipients though such recipients should only receive such token amounts on to_chain A and not on to_chain B.
Similarly, since the ChakraSettlement.receive_cross_chain_callback function does not ensure that the receiving ChakraSettlement contracts contract_chain_name must match the to_chain associated with its txid input, the signatures that should only be used for calling the ChakraSettlement.receive_cross_chain_callback function on to_chain A can also be allowed to be used on to_chain B. As a result, to_chain Bs handlers receive_cross_chain_callback function logics can be incorrectly triggered, such as burning the corresponding token amount held by such handler on to_chain B under the MintBurn mode though such token amount should only be burned on to_chain A and not on to_chain B.
When a validator is deterministically deployed, it can have the same address on different chains. When a handler is deterministically deployed, it can have the same address on different chains. Therefore, it is possible that the validators have the same addresses on two different to_chain chains while the number of required validators are the same on both chains, and the handler has the same address on these two to_chain chains as well. Moreover, such handler can whitelist the same from_chain-from_handler combination on both to_chain chains.
Suppose such situation occurs for to_chain A and B, the validators on to_chain A can sign for a cross-chain message in which such signatures should only be used on to_chain A and should not be allowed to be used on to_chain B. However, since the ChakraSettlement.receive_cross_chain_msg function does not ensure that the receiving ChakraSettlement contracts contract_chain_name must match the to_chain corresponding to its txid input, the ChakraSettlement.receive_cross_chain_msg function on to_chain B can be successfully called with the txid, from_chain, from_address, from_handler, to_handler, and payload, which were encoded in the signed message hash for the signatures that should only be used on to_chain A.
In this case:
Thus, such ChakraSettlement.receive_cross_chain_msg function call on to_chain B would be successful, which causes such signatures that should only be used for calling the ChakraSettlement.receive_cross_chain_msg function on to_chain A to also be allowed to be used on to_chain B.
https://github.com/code-423n4/2024-08-chakra/blob/f61c899c22492bdf5bdcb07cdb62ea9b4cd38825/solidity/settlement/contracts/ChakraSettlement.sol#L170-L244
https://github.com/code-423n4/2024-08-chakra/blob/f61c899c22492bdf5bdcb07cdb62ea9b4cd38825/solidity/handler/contracts/ChakraSettlementHandler.sol#L300-L355
Similarly, when the same situation occurs for to_chain A and B, the ChakraSettlement.receive_cross_chain_callback function on to_chain B can also be successfully called with the txid, from_handler, to_handler, and status, which were encoded in the signed message hash for the signatures that should only be used on to_chain A, because the ChakraSettlement.receive_cross_chain_callback function does not ensure that the receiving ChakraSettlement contracts contract_chain_name must match the to_chain associated with its txid input.
For the same reasons described for the case involving the ChakraSettlement.receive_cross_chain_msg function, calling the ChakraSettlement.receive_cross_chain_callback function in this case would cause signature_verifier.verify(message_hash, signatures, sign_type) to return true, ISettlementHandler(to_handler).receive_cross_chain_callback to be called successfully, and is_valid_handler(from_chain, from_handler) to be true when further calling the ChakraSettlementHandler.processCrossChainCallback function. Hence, such ChakraSettlement.receive_cross_chain_callback function call on to_chain B would be successful, which causes such signatures that should only be used for calling the ChakraSettlement.receive_cross_chain_callback function on to_chain A to also be allowed to be used on to_chain B.
https://github.com/code-423n4/2024-08-chakra/blob/f61c899c22492bdf5bdcb07cdb62ea9b4cd38825/solidity/settlement/contracts/ChakraSettlement.sol#L256-L283
https://github.com/code-423n4/2024-08-chakra/blob/f61c899c22492bdf5bdcb07cdb62ea9b4cd38825/solidity/settlement/contracts/ChakraSettlement.sol#L285-L301
https://github.com/code-423n4/2024-08-chakra/blob/f61c899c22492bdf5bdcb07cdb62ea9b4cd38825/solidity/settlement/contracts/ChakraSettlement.sol#L303-L331
https://github.com/code-423n4/2024-08-chakra/blob/f61c899c22492bdf5bdcb07cdb62ea9b4cd38825/solidity/handler/contracts/ChakraSettlementHandler.sol#L365-L396
The ChakraSettlement.receive_cross_chain_msg and ChakraSettlement.receive_cross_chain_callback functions can be updated to check if the receiving ChakraSettlement contracts contract_chain_name matches the to_chain associated with the respective txid input and revert if not matched.
0xsomeone (judge) increased severity to High and commented:
