Repository navigation
fix: reject IBC transfers sent from internal addresses in the IBC VP (backport #5052) - #5060
Merged
Merged
Conversation
An ICS20 `MsgTransfer` whose packet sender is the IBC escrow (`#IBC`) was accepted: escrowing the sent tokens is a no-op transfer from the escrow to itself, so no balance changes, while the withdraw counter and the packet commitment are still written. The counterparty then mints vouchers which can be returned to release genuine escrowed tokens, and since no balance key changes the rate limits were skipped too. Burning vouchers held in escrow, or sending NFTs held in escrow, abuses the same missing authorization. The IBC VP now rejects any (NFT) transfer whose sender is an internal address. The fix lives only in the native VP, so the wasm txs are unchanged. The IBC message is now decoded once in the VP and shared by the sender and rate limit checks. Add regression tests running the real `tx_ibc.wasm`, sharing the IBC channel setup with the existing escrow drain tests. (cherry picked from commit 6279d76)
The `outgoing_shielded_action` bench built its ICS20 `MsgTransfer` with the effective address of the source as the packet sender. For a shielded source that is the MASP internal address, which the IBC VP now rejects: no tx can authorize a transfer on behalf of a protocol-owned address. Real shielded sends are unaffected: the SDK uses a transparent refund address as the packet sender, while the funds are still drawn from the MASP through the shielded section of the tx. Mirror that behavior in the bench, so it exercises the txs actually produced in practice. (cherry picked from commit c1f15a2)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
An ICS20
MsgTransferwhose packet sender is the IBC escrow (#IBC) was accepted: escrowing the sent tokens is a no-op transfer from the escrow to itself, so no balance changes, while the withdraw counter and the packet commitment are still written. The counterparty then mints vouchers which can be returned to release genuine escrowed tokens, and since no balance key changes the rate limits were skipped too. Burning vouchers held in escrow, or sending NFTs held in escrow, abuses the same missing authorization.The IBC VP now rejects any (NFT) transfer whose sender is an internal address. The fix lives only in the native VP, so the wasm txs are unchanged. The IBC message is now decoded once in the VP and shared by the sender and rate limit checks.
Add regression tests running the real
tx_ibc.wasm, sharing the IBC channel setup with the existing escrow drain tests.Describe your changes
Checklist before merging
breaking::labelsnamada-docsreponamada-indexerornamada-masp-indexer, a corresponding PR is opened in that repoThis is an automatic backport of pull request #5052 done by [Mergify](https://mergify.com).