Submitted by fyamf
It is possible to bridge assets from Starknet to Starknet by setting to_chain and to_handler to be the same as from_chain and from_handler. This violates the core rule of the protocol, which is The contract maintains a consistent state between locking/burning tokens on the source chain and minting/unlocking on the destination chain, depending on the settlement mode.
For example, this could result in the total supply of ckrBTC on Starknet being higher than the amount of BTC transferred to MuSig2 on the Bitcoin network.
When a message is received on Starknet, the handler_erc20::receive_cross_chain_msg function is called:
Link to code
In this function, it checks that both to_chain and to_handler as well as from_chain and from_handler are supported:
Link to code
to_chain must be the Starknet chain name, and to_handler must be the contract address of handler_erc20.
This check forces the owner to already call set_support_handler to add support for to_chain and to_handler. Otherwise, any call to handler_erc20::receive_cross_chain_msg will fail:
Link to code
At first glance, this seems redundant. Why should the Starknet chain and its handler be added to the support_handler mapping within the same handler? For example, if the chain name is Starknet and the handler address is 0xaa, calling support_handler.read('Starknet', 0xaa) returns 1. This mapping should only record valid destination chains and handler addresses, not its own chain and handler.
This creates a potential attack:
Link to code
This contradicts the core logic of the protocol, as explained:
Link to source
This means that the amount of ckrBTC on Starknet is supposed to match the amount of BTC transferred to MuSig2. However, due to this attack, the amount of ckrBTC on Starknet can be maliciously increased and will not match the amount of BTC transferred to MuSig2.
Under normal conditions, a user locks ckrBTC on Starknet and receives tokens on another chain, enabling them to use Bitcoin-backed assets in DeFi protocols. But in this attack, the attacker locks ckrBTC on Starknet and bridges it to Starknet again to mint ckrBTC again. This causes the total supply of ckrBTC on Starknet to be higher than the amount of BTC in MuSig2, violating the core rule of the protocol.
This vulnerability does not depend on owner mistakes. The owner must have already added the source chain and handler to the support_handler mapping; otherwise, any call to handler_erc20::receive_cross_chain_msg would fail. On the EVM-based code, however, the owner does not need to add the source chain and handler to the handler_whitelist mapping, since ChakraSettlementHandler::receive_cross_chain_msg only checks that from_chain and from_handler are whitelisted, not to_chain and to_handler.
Link to code
In the following test, target_chain, target_token, and target_handler are all set to Starknet, ckrBTC, and erc20_handler on Starknet, respectively. This shows that the transaction executes successfully, contrary to expectations.
When bridging from Starknet, it should ensure that the source and destination are different.
0xsomeone (judge) decreased severity to Medium and commented:
