Chromia security record

In `withdrawBySnapshot()`, the `ERC20StateHeader` is validated to confirm that the withdrawal snapshot is intended for the bridge contract. A snapshot can either be authorized for any bridge on a given network, or a specific bridge on the network. The relevant code is reproduced below: ```js // assume networkId must fit in 96 bits uint256 allowedDiscriminator1 = networkId << 160; // discriminator allows any bridge contract on the network uint256 allowedDiscriminator2 = allowedDiscriminator1 + uint160(address(this)); require((header.discriminator == allowedDiscriminator1) || (header.discriminator == allowedDiscriminator2), "TokenBridge: invalid bridge contract"); ``` <br> `hbridge/snapshot.rell` indicates that the open discriminator is used as a default: ```js function network_id_to_discriminator(network_id: integer): big_integer { return big_integer(network_id) * big_integer.from_hex("1" + "00".repeat(20)); } function maybe_create_local_erc20_state_slot(account: ft4.accounts.account, erc20_asset): state_slot? { .... if (not exists(existing_slot)) { existing_slot = create state_slot ( id = get_next_state_slot_id(), network_id, recipient_address = account_address, type = state_slot_type.erc20, discriminator = network_id_to_discriminator(network_id), // Open discriminator local = true ); } .... } ``` <br> If a mass exit is triggered across multiple bridges on the same network, then `header.discriminator == allowedDiscriminator1` would allow users to call `withdrawBySnapshot()` across different bridges.

In `TokenBridgeWithSnapshotWithdraw.triggerMassExit()`, the owner assigns the `massExitBlock` as the last valid block from which users can call `withdrawBySnapshot()`. The block is required to have occurred within the last three days: ```js require(header.timestamp >= (block.timestamp - 3 days) * 1000, "TokenBridge: mass exit block is too old"); ``` <br> Given that the requirement is hardcoded to 3 days, this duration may be longer than the dispute period if `withdrawOffset` is shorter than 3 days. This would allow users who executed their withdrawals to withdraw additional funds via the older snapshot.

The entity `evm_block` has three keys: 1. `network_id` 1. `evm_block_height` 1. `evm_block_hash` <br> This would allow a given `<network_id, evm_block_height>` pair to be associated with multiple `evm_block_hashes`, which could cause inconsistencies when processing blocks.

The `TokenBridge` contract has had its storage layout refactored since the previous audit, with some variables removed/added across the `ChromiaTokenBridge` and `TokenBridgeWithSnapshotWithdraw` contracts. This makes the new `TokenBridge` incompatible for upgrading previous versions. After speaking with the Chromia team, none of the deployed instances of the `TokenBridge` contract are scheduled for upgrades, and thus the severity of the issue has been marked as Informational.

While not an issue in and of itself, the FT4 library may have some default behaviors that will be unexpected for users/developers from other ecosystems. When integrating the library, developers should confirm whether this is the desired behavior for their dapp and make any necessary adjustments. Additionally, users should be aware of the possibility of these behaviors before interacting with a dapp. A non-exhaustive list of these behaviors includes: * `rell/src/lib/ft4/external/admin/operations::mint()`: The admin can mint any amount of an asset without restriction. * `rell/src/lib/ft4/external/assets/operations::burn()`: Unlike the ERC-20 standard in which burning is a custom extension, the FT4 library has burning enabled as a default. More specifically, a user can decide to burn their own assets.

`get_first_allowed_auth_descriptor()` makes a call to `get_auth_handler(op_name).resolver()`. The resolver will go through the list of auth descriptors and return the first allowed one. However, there is no validation that the auth descriptor isn't violating any rules. This can result in valid auth descriptors being ignored.