Chromia security record

Function `process_deposit_erc20_event()` may falsely assume the deposit origin. Consider the following code segment: ```js function process_deposit_erc20_event(network_id: integer, event: deposited_erc20_event) { var beneficiary = event.beneficiary; val deposit_from_smart_contract = beneficiary != zero_beneficiary; ... } ``` <br> A `beneficiary == zero_beneficiary` may incorrectly assign `deposit_from_smart_contract` due to the following: 1. `TokenBridge.deposit()` being callable not only from EOAs but also from smart contracts. 1. `TokenBridge.depositToAccountID()` allowing for `accountID ` (on RELL side `beneficiary`) being passed in as zero. 1. `TokenBridge.withdrawToPostchain()` defaulting the `accountID` to `0x0`. <br> While most of the deposit functionality will still work with an incorrect `deposit_from_smart_contract`, we identified the following impacts: 1. Smart contracts do not require an explicit link to an FT4 account to process a deposit. 1. Completed deposits may be incorrectly marked as pending. <br> ### Smart Contracts Do Not Require an Explicit Link to a FT4 Account The function `process_deposit_erc20_event()` will require an explicit link between a smart contract and a FT4 account to prevent unwanted deposits, as indicated by the following code: ```js if (deposit_from_smart_contract) { ft4_account = ft4.accounts.account @? { .id == beneficiary }; if (not empty(ft4_account)) { // we require explicit link to avoid unwanted deposits if (need_consent_on_deposit and empty(evm_sc_account_link @? { event.sender, network_id, ft4_account })) { bounce_deposit_event(network_id, event.token_address, event.sender, event.amount); return; } } } ``` <br> If `deposit_from_smart_contract` is incorrectly assigend to `false`, then this requirement will be skipped and FT4 accounts may receive unwanted deposits. <br> ### Completed Deposits May Be Incorrectly Marked as Pending Pending deposits made to Chromia can be collected once an FT4 account is registered. ```js function _link_evm_sc_account(address: byte_array, network_id: integer, account: ft4.accounts.account) { require(empty(evm_sc_account_link @? { address, network_id }), "EVM address %s on EVM chain ID %d is already linked to FT4 account".format(address, network_id)); create evm_sc_account_link(address, network_id, account); // there's a possibility that the account_id is different from address hash // collect funds from the pool account here ft4.transfer_strategy.collect_pooled_assets(account, recipient_id = address.hash()); val pending_deposits = erc20_deposit @* { .sender_address == address, deposit_state.pending, .from_smart_contract == true }; for (deposit in pending_deposits) { update_deposit_state(deposit, deposit_state.completed); } after_evm_account_linked(address, account, network_id, true); } ``` <br> If `deposit_from_smart_contract` is incorrectly assigend to `false`, then pending deposits will not be found with the query `val pending_deposits = erc20_deposit @* { .sender_address == address, deposit_state.pending, .from_smart_contract == true };`. They will remain in status `pending` despite having been collected. `hbridge/operations.recall_pending_deposit()` would still prevent the recall of such a transfer in `ft4.transfer_strategy.recall_transfer()` and we could not find an exploit. However, future functionality that queries the `.deposit_state.pending` field may not work as intended.