2023-02-10 Audit Report - ICS replicated security

Security Audit Report

Interchain Security v.1.0: Provider Chain Safety

10.02.2023 Last revised 14.02.2023

Contents Audit overview 3 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Conducted work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Further Increasing Confidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Audit Dashboard 5

System Overview 6 Block Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Adding and removing consumer chains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Reward distribution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Throttling overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Overview of Cosmos SDK changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Threat Inspection 14 Threat: Provider halts or its state is corrupted . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Threat: Unbondings are delayed or don’t complete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Threat: Validators are harmed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Findings 19 A byzantine consumer can tombstone, slash, or jail an innocent validator . . . . . . . . . . . . . . . . . . 20 Consecutive meter replenishments when the meter is negative . . . . . . . . . . . . . . . . . . . . . . . . . 21 Panics on failure to send IBC packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Unbonding period on consumers is not enforced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 A consumer can delay unbonding period on the Hub to be up to 35 days . . . . . . . . . . . . . . . . . . . 26 A byzantine consumer might inflict Denial-Of-Service to other consumers . . . . . . . . . . . . . . . . . . 27 Suboptimal integration of changes into Cosmos SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Problems that harm code readability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Appendix: Vulnerability classification 30

Audit overview The Project Interchain Security (ICS) is a feature that is about to be added to the Cosmos Hub. ICS allows smaller chains to take advantage of the Cosmos Hub strong security; these smaller chains are called consumer chains of the Hub, which is called the provider chain. ICS enables the Cosmos Hub validator set to be shared with consumers: the validators use their stake on the Hub to secure consumer chains. As a consequence, consumer chains do not have to establish their own validator sets, and the cost of attacking a consumer chain is the same as the cost of attacking the Cosmos Hub. Technically, the provider chain and the consumer chains communicate via the IBC protocol: the provider sends updates on the validator set to consumers, and each consumer informs the provider of potential infractions committed on the consumer. In that way, the provider validator set is replicated1 on every consumer chain. It is important to note that a consumer chain can only be added through a governance proposal on the provider chain. If a proposal is accepted, validating on the consumer chain becomes mandatory for all members of the validator set.

Scope of this report This is a report on the code review audit of the Interchain Security v1.0.0-rc1. The audit took place from January 16, 2023 through February 10, 2023 by Informal Systems by the following personnel: • Ivan Gavran • Andrey Kuprianov • Andrija Mitrovic The audit was a part of a larger effort to make sure that ICS is ready for the Cosmos Hub upgrade. Before starting the work on this audit, Ivan Gavran and Andrey Kuprianov were engaged in providing security feedback on the ICS work-in-progress implementation. In this audit, we focused our attention on the security of the provider chain with ICS enabled. We note that ICS is organized in a specific way: once added to the provider chain, it should not make any difference until the first consumer chain is added. Thus, in our analysis of the code, we always differentiate between three setups: the provider chain with ICS but no consumers, the provider chain with ICS and trustworthy consumers, and, finally, the provider chain with ICS and byzantine consumers (consumers that can behave in arbitrary ways, including buggy or malicious behaviors). We emphasize these scenarios because each consumer chain will be admitted in a separate governance proposal, likely receiving additional scrutiny. Regardless of the low likelihood of a completely arbitrary behavior, we flag potential issues that could arise in the case of byzantine consumers.

Conducted work The audit team started its work on January 16th. The development team gave us an initial overview of the codebase, followed by more detailed walkthroughs of specific parts in the weeks that followed. The audit team engaged in reviewing the code of different components of the ICS implementation, as well as examining the throttling protocol. 1 A note on naming: the ICS feature is sometimes called Replicated Security, which is a more specific term than Interchain Security.

However, we will use the term Interchain Security throughout this report to maintain consistency with the codebase name.

Timeline • week 1: Code overview by the dev team, the audit team working on inspecting the system with no consumers. • week 2: Walkthroughs of different features, the audit team inspecting the throttling mechanism and the addition of consumer chains. • week 3: The audit team inspecting the exchange of VSC messages, slashing requests, and distribution of rewards.

Conclusions Overall, we found the codebase to be of high quality: specification is complete and well-written, the code is well-structured and easy to follow, and the test suite includes unit tests, integration tests, and end-to-end tests. Some of the tests are based on a simplified implementation of the protocol, which functions as a model to compare the implementation to. The main problem we found was an over-reliance on trustworthiness of consumers and not requiring any evidence of misbehavior. Based on that feedback, the development team implemented a reduction in consequences validators could face if a consumer chain reports their misbehavior, and is working on a release that would rely on evidence of misbehavior. Despite the general high quality, we found some details that should be addressed in order to raise the quality of code and existing specification. One High Severity issue was found during this audit; the rest were marked Medium, Low or Informational severity.

Further Increasing Confidence The scope of this audit was limited to manual code review and manual analysis and reconstruction of the protocols. We are aware that the ICS team ran a separate protocol audit in which the protocol’s TLA+ model was checked by a formal verifier. To further increase confidence in the implementation, we recommend augmenting the existing test suite with TLA+ model-based adversarial testing. This would also make it easier to maintain the test suite in the event of future changes to the codebase. It is our understanding that the Interchain Security team intends to pursue such measures to further improve confidence in their system.

Audit Dashboard Target Summary • Type: Specification and Implementation • Platform: Golang • Artifacts: – ICS28 Cross Chain Validation: 94baa3f – Interchain Security: v1.0.0-rc1 – Cosmos SDK: v0.45.11-ics, specifically the changes wrt v0.45.11

Engagement Summary • Dates: 16.01.2023 to 10.02.2023 • Method: Manual code review & protocol analysis • Employees Engaged: 3

Severity Summary

Finding Severity # Critical 0 High 1 Medium 2 Low 3 Informational 2 Total 8

System Overview Interchain Security introduces an option for new or existing blockchains to lease security from a larger blockchain. The (smaller) blockchains that lease security are called consumer chains, and the (larger) blockchain that provides security is called the provider chain. Validators of the provider chain will additionally validate on consumer chains using their stake from the provider. In effect, misbehavior on any of the consumers becomes equally costly as misbehavior on the provider itself. Importantly, a consumer can only be added through a governance proposal on the provider. In this section, we give a high-level overview of the system, which will be useful for understanding the rest of the report. For more details on the system, see the specification file or the documentation. In order to achieve the replication of security, the provider (P ) and a consumer (C) are exchanging the following messages over IBC: • P → C: Validator Set Change (VSC). This message makes sure that the consumer chain keeps up with the changes of the validator set on the provider chain. • C → P : VSC matured. This message is sent once the consumer’s unbonding period has elapsed upon receiving the VSC. Without receiving this message, the provider chain will not unbond the relevant stake (because that stake is still used on the consumer). • C → P : Slash requests. Upon noticing misbehavior of a validator, the consumer will send a request to the provider to slash the stake of the misbehaving validator, and jail or tombstone the validator. • C → P : Rewards. Periodically, the consumer transfers reward tokens to the distribution account of the provider chain. These tokens have been accumulated in a separate account on the consumer chain at the beginning of every block. The first three messages are sent over the same, ordered channel. The last message, which sends rewards to the provider, is sent over a separate, unordered channel. Note that there is no assumption of consumers and the provider being synchronized. In the next subsection, we will go into more detail on how the exchanged messages provide a necessary synchronization mechanism, as well as the block structure of both the provider and consumers.

Block Structure Let us dive deeper into how the provider and a single consumer are interacting. We will use Figure 1 as a schematic representation of the interaction. On the left side of the figure (in blue) we see the provider chain, and on the right side (in red) we see the consumer chain. Two blocks of both chains are shown. (As mentioned earlier, blocks can be produced at arbitrary speeds, and the two shown blocks are not necessarily consecutive.) Each block is separated into three parts: the upper part denotes the BeginBlock method, the middle part denotes handling of transactions (DeliverTx method), and the lower part denotes the EndBlock method. The messages of the ordered channel are denoted by arrows. (The messages of the unordered transaction channel are not shown in the figure.) In the provider’s BeginBlock method, updates to the validator set are applied. These updates will be sent to the consumer in the EndBlock. You will notice that they are first enqueued and only then sent to the consumer. This is a common pattern in the communication scheme and it makes sure that if the consumer’s channel is not yet established, the updates get preserved and are sent only once the consumer is ready to receive them. (The figure uses a shorthand enQ for enqueue.) Prior to enqueueing and sending the updates to the consumer, the EndBlock also slashes the stake of misbehaving validators. It does so per the consumer’s report. Importantly, it does not require proof of misbehavior from the consumer. Trusting the consumer chain to report misbehavior faithfully is listed as one of the assumption in the specification (see Evidence Provision). Regardless of the Evidence Provision assumption in the protocol specification, the

Figure 1: Schematic representation of the interaction between the provider and a consumer

implementation includes a mechanism to prevent a byzantine consumer from removing a large number of validators at once. This is why the figure says that validators should be removed “As much as the meter allows”. The whole mechanism is described in the section Throttling overview of this report. The provider also receives transactions notifying it that some VSCs have matured on the consumer. When they are received, these notifications are enqueued and processed in the EndBlock. If maturity notifications are received from all existing consumers, the provider informs the staking module that relevant unbonding operations can be finalized. If, however, a maturity notification for a VSC is not received for too long (the default timeout is 5 weeks), the provider will remove the consumer from the set of active consumers. This ensures that unbonding is not blocked indefinitely. Finally, when sending VSCs to the consumer in the EndBlock, the provider also sends acknowledgments for all received slash requests. On the consumer’s side, once the updates on validators’ powers (VSC packets) are received from the provider, they are enqueued (to be processed later in the EndBlock) and the maturity time is set for the VSC packet (depending on the consumer’s unbonding time). Moreover, the acknowledgments for the slash requests are used to unset the boolean flag outstandingDowntime, which is used to prevent the consumer from sending multiple slash requests for the same downtime infraction. The enqueued updates on validators’ powers are returned to the consensus engine in the EndBlock method. On top of that, EndBlock is responsible for sending slash requests (as enqueued in the BeginBlock) and for sending notifications that some VSCs have matured. Finally, the EndBlock method also accumulates rewards and sends them to the provider every period blocks (where the default value for period is 1000). The rewards are sent directly to the provider’s distribution module so there is no separate handling of rewards on the provider’s side introduced by the Interchain Security module. Thus far, we have given an overview of the standard communication scheme between the provider and a consumer. The following subsections will cover additional features of Interchain Security:

• adding and removing consumers: consumers are introduced to Interchain Security (and removed from it) using governance proposals on the provider. • reward distribution: rewards from consumers are distributed to validators. • throttling: a large number of validators cannot be removed at once.

Adding and removing consumer chains A consumer chain can be added to the provider chain only through a governance proposal. Removing a consumer chain can be triggered by a governance proposal or by various validity checks.

Proposal processing The addition and removal of consumer chains through proposals are done in two steps:

Gathering proposals, verifying them, and adding them to a queue of pending proposals.
Going through the queue of pending proposals at the beginning of each block and executing them. There are two types of proposals for the addition and removal of consumer chains:
ConsumerAdditionProposal is a governance proposal on the provider chain to spawn a new consumer chain. First, a consumer addition proposal is executed in a cached context for verification. Here, a consumer client is created if it does not already exist for the proposed consumer. After the verification, cached writes are discarded. If the verification is successful, a pending consumer addition proposal is stored. If there are multiple addition proposals for the same chain, only the last will be stored.
ConsumerRemovalProposal is a governance proposal on the provider chain to remove/stop a consumer chain. First, the consumer removal proposal is executed in a cached context for verification. After the verification, cached writes are discarded. If the verification is successful, a pending proposal for removal is set for that consumer chain.

Addition of consumer chains The addition of consumer chains through a proposal is done at the beginning of each block in the BeginBlockInit function. First, addition proposals whose spawn time is not before the current block time are acquired. Then, for each proposal, the creation of a consumer client in a cached context is done. If this passes without errors, then the cached context is written to the context. In the end, executed addition proposals are deleted from the pending list (the deletion happens whether the proposal was executed successfully or not).

Removal of consumer chains As mentioned before, removing consumer chains can be done in a few ways: • Removing consumer chains through proposal is done at the beginning of each block in the BeginBlockCCR function. First, removal proposals whose stop time is not before the current block time are acquired. Then, for each proposal, stopping the consumer chain in a cached context is done. If this passes without errors, then the cached context is written to the context. Note that for every stopped chain, the state is cleaned for the given consumer chainID and the outstanding unbonding operations are completed. In the end, executed removal proposals are deleted from the pending queue. • The consumer chain can be removed/stopped if a packet from the provider to the consumer times out with a reason that isn’t an unknown channel. • The consumer is removed/stopped if the channel still exists and the acknowledgment VSC packet from the consumer could not be successfully decoded. • The consumer chain can be removed at the end of each block for two reasons: – The consumer is not initialized on time. – Consumers for whom the maturity notification for a VSC packet was not received before the timeout.

Reward distribution overview The process of validating transactions on the consumer side is rewarded. Distribution of rewards is a process of splitting and distributing the consumer block rewards between the consumer chain itself and the provider chain. Distribution of rewards occurs at the end of each block on the consumer side. Rewards for the provider are accumulated to be transmit- ted to the provider. Transmissions occur after a predefined number of blocks passes after the last transmission. This predefined number of blocks is kept track of in the store under types.KeyBlocksPerDistributionTransmission. This process is schematically presented in Figure 2. Each consumer has three accounts for the rewards which are used for distribution: • Consumer-chain fee collector account: an account used for collecting fees on the consumer. These will be split into two parts and sent to the following two accounts at the end of each block. • Consumer-redistribution account: an account used for collecting rewards that should be redistributed on the consumer chain. • Consumer to send to provider account: an account used as a buffer for collecting rewards that

Excerpt (19997 of 72600 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation