ASA-2022-003: Dragonberry IBC-Go Security Advisory

ASA-2022-003, known as Dragonberry, is a critical security advisory for the IBC-Go implementation of the Inter-Blockchain Communication protocol. The vulnerability resides in the Interchain Accounts (ICA) host submodule, where a flaw in the packet acknowledgment logic allows a malicious controller chain to craft a fraudulent OnChanOpenConfirm handshake. This bypasses the fundamental trust assumption that a host chain should only execute transactions authorized by the registered controller chain's interchain account.

The operational consequence is a complete compromise of all funds held in escrow by the ICA host module on an affected chain. A malicious or compromised controller chain with an open ICA channel can drain tokens from the host chain without triggering standard security checks. The blast radius extends to every IBC-connected chain running a vulnerable version of IBC-Go (>= v2.0.0 and < v5.1.0) that has authorized at least one ICA channel. This is not a theoretical attack; it is a direct violation of the security model that underpins cross-chain account control.

Chain teams must treat this as an emergency patch event. Verification requires confirming the exact IBC-Go version, auditing all active ICA channels for unauthorized controller chains, and applying the patched release immediately. Chainscore Labs provides cross-chain security review for teams needing to assess their ICA host configurations, validate the patch against their state machine, and coordinate a synchronized upgrade with their validator set.

The vulnerability resides in the ibc-go implementation of the ICS-27 Interchain Accounts standard, specifically within the host chain's packet handling logic. The core trust model of ICA dictates that a host chain should only execute transactions authorized by the interchain account's owner on the controller chain. The Dragonberry bug allows a malicious controller chain to craft an ICA packet that bypasses this authorization check. By manipulating the packet data, an attacker could cause the host chain to execute arbitrary MsgExecuteContract or Bank.MsgSend messages as if they originated from the legitimate interchain account owner, effectively granting the attacker full control over the associated account and its assets on the host chain.

The technical mechanism involves a failure in how the host module validates the AuthenticateTx callback during OnRecvPacket. The host chain relies on the controller chain to correctly serialize the owner's authentication into the packet's Data field. The vulnerability allows a malicious controller to construct a packet with a crafted Data field that, when deserialized by the host, satisfies the authentication predicate without a valid signature from the true owner. This means the host chain's state machine can be tricked into believing a transaction was authorized by the legitimate interchain account owner when it was not, violating the sovereignty and security of the host chain. Any chain with the ICA host module enabled and an open channel to a potentially malicious controller chain was at risk.

The operational impact is severe and cross-chain in nature. A compromised or malicious controller chain could drain all funds held by its interchain accounts on every connected host chain. This transforms a security incident on one chain into a systemic cross-chain event. For host chains, the immediate remediation required an emergency upgrade to a patched ibc-go version that correctly validates the authentication data. For controller chains, the advisory mandated verifying their own integrity and the security of their validator set, as a compromised controller could be used as a launchpad for attacks against all its connected hosts. Chainscore Labs can assist host chain teams in auditing their ICA channel authorization logic and verifying the integrity of their IBC-Go patch to ensure this trust assumption is fully restored.