Full Report
In the Cosmos ecosystem, there is a cross chain communication framework called Interblockchain Communcation or IBC for short. On top of IBC, there is a middleware called Packet Forwarding Module (PFM). PFM will take an incoming IBC tx and forward it to the next chain in the list, allowing for multi-hop calls. There are several parties involved with this: Source chain: The blockchain that initiates the original IBC message. Intermediary chain: The blockchain(s) that the PFM packet goes through in order to get to the destination. Destination chain: The location in which the original packet was meant to be routed to. When using ICS20 (which PFM uses) for token transfers, the memo stores the routing. Within ICS20, there is some magic that happens for handling assets from other chains. When going from the source to the destination, the tokens are escrowed in the source chain then a representation is minted on the destination. When going backwards, the minted token is burned and the escrowed token is unlocked. Because PFM is doing magic to route multiple ICS20 calls, there is a chance for error here. PFM handles the responses from the destination chain to source chain for successes, errors and timeouts. However, some users were attempting to perform another PFM after their interactions on the destination chain back through the intermediary and source chain. When doing this, the internal accounts of funds got messed up when handling the error path. In particular, the escrow account on the intermediary chain was not properly updating the total supply. Since the escrowed account only has so many funds, this could result in funds being inaccessible from the errors. According to the post, this bug was discovered while trying to debug an IBC client on a real network. Yikes! Luckily, it wasn't possible to steal funds using this issue. The developers said that this wasn't caught because of missing test cases in their end to end test setup. They urge deves to write good unit, integration and e2e tests whenever possible. Another interesting bit to this is testing IBC applications is hard to do - you need to setup multiple blockchains for multiple situations, which is difficult.
Analysis Summary
# Vulnerability: Intermediary Chain Escrow Account Imbalance in PFM Multi-Hop Error Paths
## CVE Details
- CVE ID: Not explicitly assigned in the provided text.
- CVSS Score: Not explicitly assigned; severity was determined to be **Medium**.
- CWE: CWE-770 (Improper Handling of Error Conditions/Resource Management related to supply accounting) might be conceptually related, pending formal assignment.
## Affected Systems
- Products: Cosmos SDK Interblockchain Communication (IBC) middleware **Packet Forwarding Module (PFM)** (`packet-forward-middleware`).
- Versions: **All supported versions** of the PFM middleware.
- Configurations: Occurs during specific multi-hop ICS20 token transfers where a transaction path involves an intermediary chain, and an error (timeout/acknowledgement failure) is encountered when returning tokens back across the hop path.
## Vulnerability Description
The vulnerability stems from incorrect internal bookkeeping logic within the Packet Forwarding Module when an ICS20 (token transfer) transaction involving multi-hop forwarding (via PFM) fails during the error path response back to the source chain.
Specifically, when a token is sent source -> intermediary -> destination, and the user attempts a subsequent multi-hop transaction to return the tokens back (destination -> intermediary -> source), failures (timeouts or acknowledgement errors) during this return path cause the escrow account on the **intermediary chain** to be improperly updated. This results in the **escrow account balance being less than the total supply of the corresponding token on the counterparty chain**, leading to an imbalance.
Crucially, this did **not** allow for fund *theft*, but it could render assets *inaccessible* because the supply tracking was broken, resulting in a state where users could not unwind (return) their tokens back to the original source chain.
## Exploitation
- Status: **Not exploited** (The flaw was discovered via manual debugging on a production network). PoC is not detailed.
- Complexity: Likely **Medium**, as it requires setting up a specific multi-hop traversal and triggering an error condition in the return path.
- Attack Vector: Network (Requires interaction with the IBC/PFM messaging infrastructure).
## Impact
- Confidentiality: No impact.
- Integrity: **Partial Integrity Impact**. The integrity of the token supply accounting was compromised on the intermediary chain's escrow account, leading to potential unavailability of unwinding mechanisms for affected tokens.
- Availability: **Partial Availability Impact**. Users could face a form of Denial-of-Service where they cannot unwind their assets back to the original chain until the state is manually corrected.
## Remediation
### Patches
- Chain developers must upgrade to the patched version of `packet-forward-middleware` found in the `cosmos/ibc-apps` repository releases. (Specific version numbers are not listed, but users should consult the releases page.)
### Workarounds
1. **Balance Checking:** Programmatically check the balance of every affected IBC escrow account against the total supply of the corresponding asset on the counterparty chain. Strangelove provided an escrow checker tool for this purpose.
2. **State Correction:** If a discrepancy is found (escrow balance < counterparty supply), chain upgrade handlers must be built to mint and transfer the requisite assets to the affected escrow account(s) to correct the imbalance. An example upgrade handler was provided by the discoverer.
## Detection
- Indicators of Compromise: An external audit or balance check revealing that the balance in an IBC escrow account on an intermediary chain is lower than the total supply tracked on the destination chain for that asset.
- Detection Methods and Tools: Use the provided escrow checker tool or custom logic to compare escrow balances against the counterparty total supply for all IBC assets traversing PFM hops.
## References
- Vendor Advisories: Referenced in a security report by Composable Finance/Strangelove and private disclosure process to impacted parties.
- Relevant Links:
- Code Repository: hxxps://github.com/cosmos/ibc-apps/tree/main/middleware/packet-forward-middleware
- Patch Releases: hxxps://github.com/cosmos/ibc-apps/releases
- Escrow Checker Tool: hxxps://github.com/strangelove-ventures/escrow-checker
- Example Upgrade Handler: hxxps://gist.github.com/jtieri/0b41fa96eac44ea1c0b5de63d23aa662