Mandrake Vulnerability
Summary
Chains utilizing versions of packet-forward-middleware from before the release of these patched versions are susceptible to a vulnerability that can lead to an escrow account having a balance that is less than the total supply of an IBC denom token on a counterparty chain. This could cause a Denial-of-Service condition where users are temporarily unable to unwind their IBC assets through the affected chain.
NOTE: this does not affect all packet-forward-middleware transfers, only those that involve a timeout or acknowledgement error for a token that is wrapped two or more times.
Vulnerability Details
When native tokens from a source chain move through an intermediary chain using packet-forward-middleware a voucher representing these tokens will be minted on the destination chain and the balance of an escrow account, associated with the {port, channel} that the tokens moved through, will be updated to reflect the current total number of vouchers that have been minted on the counterparty.
In packet-forward-middleware, if a token was transferred from a source chain, forwarded through an intermediary chain(s) using packet-forward-middleware, received on a destination chain, and then the user attempted to do another multi-hop transaction to send those same tokens back through the intermediary chain(s) to the original source chain, the internal bookkeeping in the escrow accounts was not properly handled. Essentially, when the multi-wrapped IBC denom token was moved back through the intermediary chain, packet-forward-middleware was failing to properly handle timeouts and acknowledgement errors, such that these failures, in this particular scenario, resulted in the escrow account on the intermediary chain not being properly updated to reflect the total supply of the asset on the counterparty chain.
This bug would result in the escrow account on the intermediary chain failing to properly reflect the total supply of the IBC denom asset, which could result in users being temporarily unable to redeem their tokens on the intermediary chain.
Recommended Actions
We recommend that you upgrade to one of the patched versions, create a new patch release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.
In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.
Additional Information
Read the full report on the Strangelove blog.
For additional details or inquiries, please contact us at [email protected].
Mandrake Vulnerability
Summary
Chains utilizing versions of packet-forward-middleware from before the release of these patched versions are susceptible to a vulnerability that can lead to an escrow account having a balance that is less than the total supply of an IBC denom token on a counterparty chain. This could cause a Denial-of-Service condition where users are temporarily unable to unwind their IBC assets through the affected chain.
NOTE: this does not affect all packet-forward-middleware transfers, only those that involve a timeout or acknowledgement error for a token that is wrapped two or more times.
Vulnerability Details
When native tokens from a source chain move through an intermediary chain using packet-forward-middleware a voucher representing these tokens will be minted on the destination chain and the balance of an escrow account, associated with the {port, channel} that the tokens moved through, will be updated to reflect the current total number of vouchers that have been minted on the counterparty.
In packet-forward-middleware, if a token was transferred from a source chain, forwarded through an intermediary chain(s) using packet-forward-middleware, received on a destination chain, and then the user attempted to do another multi-hop transaction to send those same tokens back through the intermediary chain(s) to the original source chain, the internal bookkeeping in the escrow accounts was not properly handled. Essentially, when the multi-wrapped IBC denom token was moved back through the intermediary chain, packet-forward-middleware was failing to properly handle timeouts and acknowledgement errors, such that these failures, in this particular scenario, resulted in the escrow account on the intermediary chain not being properly updated to reflect the total supply of the asset on the counterparty chain.
This bug would result in the escrow account on the intermediary chain failing to properly reflect the total supply of the IBC denom asset, which could result in users being temporarily unable to redeem their tokens on the intermediary chain.
Recommended Actions
We recommend that you upgrade to one of the patched versions, create a new patch release for your chain binary, and coordinate an upgrade with validators as soon as reasonable.
In addition to patching packet-forward-middleware, it is imperative that you check the balances of each escrow account against the total supply of each asset on the associated counterparty chain. Failure to verify parity between the escrow accounts and the counterparty total supply can result in a type of Denial-of-Service where users may not be able to unwind their assets through your chain. You can use our escrow checker tool or whatever means you deem fit to validate these balances against the counterparty total supply. If a discrepancy is found, you will need to build an upgrade handler that mints and transfers assets to the escrow account(s) with the discrepancy. Strangelove has provided an example upgrade handler or you can see the upgrade handler used by the Cosmos Hub.
Additional Information
Read the full report on the Strangelove blog.
For additional details or inquiries, please contact us at [email protected].