2024-08-16 IBC and MASP integrations Final Report

Security Audit Report

Anoma 2024 Q3

Authors: Andrija Mitrovic, Ivan Golubovic, Manuel Bravo

Table of Contents Audit Overview ............................................................................................................ 1 Scope 1 Conclusion 1 Audit Dashboard ......................................................................................................... 2 Target Summary 2 Engagement Summary 2 Severity Summary 2 Threat Analysis ............................................................................................................ 3 Safety Properties 3 Liveness Properties 7 Findings ....................................................................................................................... 9 Incorrect Balance Updates in IBC Transfer Handling 10 Potential Token Loss Due to Refund Transaction Failures 12 Potential Issues with Handling Multiple MASP Actions 14 Redundant Field in Shielding Data Structure 16 Non Automatic Updating Mint Limit Could Lead to Rejecting Valid Transfers 17 Duplicated Checks in MASP VP and IBC VP 19 Minor Code Improvements 21 Appendix: Vulnerability Classification ..................................................................... 23 Impact Score 23 Exploitability Score 23 Severity Score 24 Disclaimer.................................................................................................................. 26 © 2024 Informal Systems Anoma 2024 Q3

Audit Overview Scope In July 2024, Informal Systems has conducted a security audit for IBC integration into Namada. The audit aimed at inspecting the correctness and security properties of the solution. The components under scope are: • IBC integration (integration of ibc-rs into Namada’s validity predicate execution model) • /crates/ibc • crates/namada/src/ledger/native_vp/ibc/mod.rs • crates/namada/src/ledger/native_vp/ibc/context.rs • MASP integration (integration of the MASP with IBC) • crates/namada/src/ledger/native_vp/masp.rs • crates/shielded_token The audit was performed from July 16th, 2024 to August 9th, 2024 by the following personnel: • Andrija Mitrovic • Ivan Golubovic • Manuel Bravo

Relevant Code Commits The audited code was from: • commit hash 012cd88b3c441ebe4a9d938a44b7fe33fc0e7ee9.

Conclusion After conducting a thorough review of the project, we found it to be carefully designed and generally well implemented. The audit was divided into two primary areas of focus: the integration of IBC-rs and the MASP (Multi- Asset Shielded Pool) Validity Predicate (VP). Given that the MASP VP had been previously audited, our attention was primarily on the new changes related to IBC integration. In the IBC integration portion of the audit, our goal was to assess whether everything necessary for the integration with IBC-rs was in place, to evaluate how the integration was carried out, and to identify any potential vulnerabilities. The absence of significant findings in this area indicates that the integration was well-executed, with no critical vulnerabilities identified. The implementation was robust, clear, and easy to understand. The MASP component, however, presented more challenges due to its complexity. We are especially grateful to the Namada implementation team, who provided invaluable assistance in helping us navigate and fully comprehend the the MASP design. The findings in this area stemmed not from poor implementation but from the inherently complex design, which involves numerous moving parts, assumptions, and dependencies on external code beyond the MASP itself. Despite these challenges, the collaboration with the Namada team allowed us to leverage our expertise to identify areas for potential improvement. Overall, the project is solid, with a well-thought-out design and a high-quality implementation. The cooperation and expertise of the Namada team greatly contributed to the success of the audit, and we believe the project is on a strong foundation moving forward.

Audit Dashboard Target Summary • Type: Protocol and Implementation • Platform: Rust • Artifacts: IBC and MASP IBC integration

Engagement Summary • Dates: 16.07.2024. - 9.08.2024. • Method: Manual code review, protocol analysis

Severity Summary Finding Severity #

Critical 2

High 0

Medium 0

Low 1

Informational 4

Total 7

Threat Analysis In our threat analysis, we start by defining a set of properties required for the correctness of the IBC integration in Namada. We separate them into safety and liveness. For each property, we define one or more threats. We then analyzed them individually to see if they could be violated, resulting in the findings presented in the Findings section. Additionally, we have inspected a set of non-functional threats related to integer-type conversions, integer overflow, and DoS attacks. We have listed them at the bottom of this section.

Safety Properties

Namada correctly implements all ibc-rs core, client and client upgradability context APIs Threat 1.1: Namada does not implement one or more context methods. Threat 1.2: Namada’s implementation of one or more context methods does not attain the IBC specification. Threat 1.3: The data passed to one or more context methods is not serialized/deserialized correctly upon storing/ retrieving. Threat 1.4: The implementation of one or more context methods does not handle "storage not responding" scenarios correctly. Threat 1.5: The implementation of one or more context methods may cause panic, which would halt the node. Conclusion: The threats do not hold. Implementation of the following ibc-rs core, client and client upgradability context APIs is checked against: • Core context APIs: These connect all the implemented IBC core modules to the host blockchain: • ValidationContext • ExecutionContext • Client context APIs: These integrate supported light clients to the host: • ClientValidationContext • ClientExecutionContext • Client Upgradability Context APIs: Enables light clients to undergo an upgrade process: • UpgradeValidationContext • UpgradeExecutionContext The first two are completely implemented, with a few functions from those traits that use default implementations. The third, Client Upgradability Context APIs are not implemented at all but this is not a problem because Namada stores the upgraded client state and consensus state by a Namada governance transaction. Chain upgrade is handled with MsgUpgradeClient . It's implemented in https://github.com/cosmos/ibc-rs/blob/ 86a0ee0d7c245592307b9bd7659bab05526cc136/ibc-core/ics02-client/src/handler/upgrade_client.rs. All APIs are implemented correctly that no of the mentioned threats are possible.
Namada’s correctly implements all ibc-rs token transfer (ICS 20) and NFT token transfer (ICS 721) APIs Threat 2.1: Namada does not implement one or more core context methods. Threat 2.2: Namada’s implementation of one or more context methods is not implemented correctly, e.g., the token escrow method does not transfer tokens from the appropriate accounts to the escrow account. Threat 2.3: The data passed to one or more context methods is not serialized/deserialized correctly upon storing/ retrieving. Threat 2.4: The implementation of one or more context methods does not handle "storage not responding"

scenarios correctly. Threat 2.5: The implementation of one or more context methods may cause panic, which would halt the node. Conclusion: The threats do not hold. Implementation of the following ibc-rs token transfer (ICS 20) and NFT token transfer (ICS 721) APIs is checked against: • Token transfer APIs (ICS 20): Implementation of escrow/unescrow and mint/burn APIs on the host chain: • TokenTransferValidationContext • TokenTransferExecutionContext • NFT token transfer APIs (ICS 721): These integrate supported light clients to the host: • NftTransferValidationContext • NftTransferExecutionContext All APIs are implemented correctly that no of the mentioned threats are possible.

Namada’s IBC validity predicate only accepts a transaction if it includes a valid IBC operation Threat 3.1: The IBC VP accepts a transaction that does not include an IBC operation and modifies IBC keys. Threat 3.2: The IBC VP accepts a transaction with an IBC operation without validating via its corresponding ibc-rs validation method. Threat 3.3: The IBC VP accepts a transaction with an IBC operation whose state changes differ from the state changes that the associated ibc-rs execution method would generate. Threat 3.4: The IBC VP accepts a transaction with an IBC operation that generates a set of events different from the events that the associated ibc-rs execution method would generate. Conclusion: The threats do not hold. IBC VP accept only transactions that have an internal address and only checks the validity of state modification under IBC keys, accepting only IBC operation whose state changes are the same as the associated ibc-rs execution method would generate. IBC VP accepts only transactions with an IBC operation that generates a set of events same as the events generated through ibc-rs execution method.
Namada’s IBC validity predicate ensures that the IBC traces are stored correctly Threat 4.1: The checks in the validity predicate do not guarantee that if a transaction is accepted and mints some tokens, then the state changes would mimic those done by the maybe_store_ibc_denom function. Threat 4.2: The IBC VP accepts transactions that include an IBC operation that changes an IBC trace key and that does not store any value with the key. Threat 4.3: The IBC VP accepts transactions that include an IBC operation that changes an IBC trace key and is associated value does not match the trace hash. Conclusion: The threats do not hold. The validation of IBC trace follows the trace hash calculation done in maybe_store_ibc_denom function on storing trace hash. It rejects transactions that include an IBC operation that changes an IBC trace key and that does not store any value with the key and the transactions that stored an invalid trace.
Namada’s IBC validity predicate ensures that IBC operations register rate limiter deposit and withdraws correctly Threat 5.1: The IBC VP accepts transactions that include an IBC operation that increases a token’s per-epoch deposit and does not register it properly, i.e., according to the add_deposit function. Threat 5.2: The IBC VP accepts transactions that include an IBC operation that increases a token’s per-epoch withdraw and does not register it properly, i.e., according to the add_withdraw function.

Namada’s IBC rate limiter prevents deposits into Namada that increase the supply to more than the allowed mint limit Threat 6.1: The IBC VP accepts transactions that include an IBC operation that mints tokens and does not register it properly, i.e., according to the update_mint_amount function. Threat 6.2: The IBC VP accepts transactions that include an IBC operation that increases the supply over the allowed mint limit. Conclusion: The threats do not hold. On transaction execute update_mint_amount function updates the minted value that is later used in limit checking, no possibility of passing a transaction that does not register properly and thus passing the mint limit check. Token minting due deposits is not possible over mint limit.
Namada’s IBC rate limiter correctly implements the per-epoch net throughput limit Threat 7.1: The check_limits function does not compute the current net throughput correctly.

Threat 7.2: The net throughput is not reset when a new epoch starts. Threat 7.3: The IBC VP does not reject transactions once the net throughput limit is reached or that would make the net throughput go over the limit. Conclusion: The threats do not hold. Throughput is calculated as a absolute difference between the deposit and withdraw value. Due to an unpredictable deposit and withdrawal occurrences it could happen that the throughput becomes larger then the throughput limit at one moment thus preventing any transfers to happen thus also preventing changes that will decrease difference between the deposit and withdraw values. In order to overcome this, on the end of each epoch the net throughput is reset.

Balances changes due to IBC messages are recorded correctly. Threat 8.1: Due to a miscalculation of the pre and post MASP balance due to an IBC operation, the MASP validity predicate rejects valid transactions. Threat 8.2: Malicious users can exploit a miscalculation of the pre and post MASP balance due to an IBC operation to get invalid transactions to pass the MASP validity predicate: burn, mint, or divert assets. Conclusion: The inspection identified the critical areas in the code where accounts balances change due to IBC messages are handled. The primary function responsible for this is is_valid_masp_transfer , which uses the changed_balances structure to determine state changes resulting from a transaction and to validate these changes accordingly. Integration with IBC introduced significant changes, notably within the validate_state_and_get_transfer_data function. Initially, the keys of the changed account balances are obtained and recorded in changed_balances via the apply_balance_change function. Here, the pre-state and post-state balances are adjusted based on actual storage values. The next phase involves updating balances based on the transaction itself. This is handled in apply_ibc_packet , which directs balance changes to specific functions depending on the transfer type:

• IBCMessage::Transfer or IBCMessage::NFTTransfer -> apply_transfer_msg • IBCMessage::Envelope -> apply_recv_message

For apply_transfer_msg , the post-state of the IBC internal address and the transfer receiving address are updated.

In terms of balance changes within changed_balances we observed the changes in the two most important accounts: • IBC Internal Address: • apply_balance_change : Updates pre-state and post-state balances. • apply_transfer_msg : Adjusts post-state by the transaction amount. • apply_recv_msg : Updates pre-state for received packets. • MASP Address: • apply_balance_change : Updates pre-state and post-state balances. • apply_transfer_msg : Adjusts post-state by the transaction amount if it involves MASP.

The inspection included checking the following transactions and their implications regarding MASP and IBC interactions:

Transaction with Envelope IBC Message (Recv, Ack, Timeout) with Shielding Transaction in the memo field.
Transaction with MsgTransfer or NFTTransfer IBC Message Interacting with MASP with Shielding Transaction via reference in ::transfer::shielded_section_hash .
Transaction with MsgTransfer or NFTTransfer IBC message without interacting with MASP but with an unrelated shielding transaction with shielding transaction via reference in the data section, unrelated to ::transfer::shielded_section_hash .

Key observations:

• The validate_state_and_get_transfer_data function incorporates changes introduced for IBC integration. It retrieves balance changes and applies them to the changed_balances structure. • Balance changes due to IBC transfers (using IBCMessage::Transfer or IBCMessage::NFTTransfer ) are handled in apply_transfer_msg . This function updates the post-state of the relevant accounts, including the IBC internal address and the transfer receiving address. Similar balance changes occur for receiving transfers via apply_recv_msg in case of receiving IBCMessage::Envelope . • For sending source transfers, the IBC internal address post-state is initially increased and then decreased by the transaction amount to prevent double-counting. • When MASP transaction is incorporated within an IBC transfer (sending or receiving), the balances of the MASP address, the IBC internal address, and the remote receiver address are updated accordingly. • The inspection considered various shielding transaction scenarios (refunding, receiving, unshielding, shielding, shielded) within IBC messages. The inspection of these threats resulted in the following findings: Incorrect Balance Updates in IBC Transfer Handling Potential Issues with Handling Multiple MASP Actions Redundant field in shielding data structure

If the MASP validity predicated accepts a transaction that modifies balances, then users of the accounts whose balances decrease have authorized the transfer. Threat 9.1: Malicious users can replay transfers without the source account owner’s authorization because the MASP VP does not check all required signatures. Threat 9.2: Malicious users can replay transfers without the source account owner’s authorization because the MASP VP does not verify signatures correctly.

Conclusion: The inspection focused on ensuring that transactions are authorized by the correct signatories and that replay protection mechanisms are correctly implemented to prevent transactions from being applied multiple times. This included verifying how signers for the transaction are collected and how their signatures are validated. Key observations: • The system identifies accounts requiring signatures based on balance changes and transparent inputs. • The code iterates over required signers, decodes their addresses, and verifies signatures against provided public keys. • A specific check is in place to prevent simultaneous credit and debit of the IBC account within a single transaction. • The signature verification mechanism plays a crucial role in preventing transaction replay. By requiring signatures from all accounts experiencing a balance decrease, the system ensures that a transaction cannot be embedded within another without the authorization of all affected parties. This protects against front- running attacks and unauthorized asset movement. The requirement for signatures from accounts with decreased balances directly addresses the risk of replay attacks without authorization. The signature verification process, including public key retrieval, threshold checks, and signature validation, helps mitigate the risk of incorrect signature verification. The threats do not hold, apart from the fact that previously mentioned finding is in relation to signatures.

Liveness Properties

Assume a transaction with a valid IBC operation is included in a committed block whose execution won't exceed the limits. The IBC validity predicate accepts the transaction. Threat 10.1: The IBC VP rejects a transaction with a valid IBC operation, i.e., one generated via the client library in wasm/tx_ibc/src/lib.rs .

Threat 10.2: The IBC rate limiter rejects a transaction that increases the supply of a token but its execution would not exceed the mint limit. Threat 10.3: The IBC rate limiter rejects a transaction that changes the per-epoch net throughput but does not make it exceed the limit. Threat 10.4: Malicious users can halt the chain (crash nodes) by submitting an invalid IBC operation that crashes the IBC VP. Conclusion: The threats do not hold. IBC VP deterministically checks the state changes on transaction execution thus valid operations will not be rejected. Rate limiter can not reject transactions that do not exceed the mint and throughput limits. No possibility of crashing the IBC VP has been found.

If a valid MASP transaction with an IBC message that has not been executed before is validated by the validity predicate, then it passes validation. Threat 11.1: Honest users cannot execute valid MASP transactions with an IBC message because the VP requires a signature from a user whose account balance did not decrease due to the execution of the

Excerpt (19995 of 47102 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation