Cosmosエコシステムセキュリティガイド：Cosmosエコシステムの異なるコンポーネントにおけるセキュリティシナリオの解体

2023.12.27

共有先

TechFlow厳選深潮セレクト

Cosmosエコシステムセキュリティガイド：Cosmosエコシステムの異なるコンポーネントにおけるセキュリティシナリオの解体

本稿では、Cosmosエコシステムにおける過去の重大なセキュリティ脆弱性の分析に加え、原因・影響・コード上の位置などに基づいて、よく見られるセキュリティ脆弱性を分類しています。

2023.12.27 - 10:45:12

Web3業界の深掘り報道に専念し潮流を洞察

執筆：CertiK

世界最大かつ最も著名なブロックチェーンエコシステムの一つであるCosmosは、ブロックチェーン間の相互運用性を重視し、異なるブロックチェーン間の効率的な連携を実現することに焦点を当てている。CelestiaやdYdX v4など、多くの主要プロジェクトがCosmos SDKおよびIBCプロトコルに基づいて構築されている。

Cosmos開発コンポーネントがますます多くの開発者の支持を得るにつれて、Cosmosエコシステムのセキュリティ問題もより広範な影響を及ぼすようになるだろう。たとえば、以前のCosmos SDKにおけるDragonfruitの脆弱性は、複数の主要パブリックチェーンの正常な動作に影響を与えた。Cosmosエコシステムの基盤コンポーネントが分散しているため、開発者は機能要件に応じてさまざまなコンポーネントを使用または拡張する必要があり、その結果、Cosmosエコシステム内のセキュリティ問題もまた分散的で多様な特徴を持つことになる。したがって、開発者がCosmosエコシステムのセキュリティ状況と対策を体系的に理解できるようにする研究資料は非常に重要である。

CertiKチームが独占公開した『Cosmosエコシステムセキュリティガイド』は、読者にとって親しみやすい分類によって、Cosmosエコシステム各コンポーネントのセキュリティシナリオを詳細に分析している。このレポートは、過去の重大なセキュリティインシデントの分析だけでなく、一般的なセキュリティ脆弱性を原因・影響・コード位置別に分類しており、Cosmosエコシステムの開発者に対して最大限のセキュリティガイダンスを提供するとともに、セキュリティ監査担当者にとってCosmos関連の監査と学習のための索引資料としても役立つ。

CertiKチームはこれまで、継続的な調査と発掘を通じて、CosmosおよびWeb3全体のエコシステムセキュリティ向上に貢献してきた。今後も定期的に各種プロジェクトのセキュリティレポートや技術研究をお届けする予定である。ぜひフォローをお願いいたします。ご質問がある場合は、いつでもお気軽にお問い合わせください。

以下に『Cosmosエコシステムセキュリティガイド』全文を掲載します👇。

概要

Cosmosはオープンソース、開放的、高度に拡張可能なブロックチェーンクロスチェーンネットワークであり、世界有数のブロックチェーンエコシステムの一つである。Cosmosは、CometBFT（旧Tendermintチーム）が開発した、異種ブロックチェーン間の通信を可能にするネットワークであり、多数の独立かつ並列に動作するブロックチェーンからなる分散型ネットワークである。そのビジョンは情報の孤島化を打破し、異なるブロックチェーン間の相互運用性を実現することにある。現在のマルチチェーン時代において、クロスチェーン連携の実現はブロックチェーン業界の切実なニーズとなっている。

Cosmosは特定の垂直領域に特化したパブリックチェーンにとって特に適した効率的なクロスチェーンモデルを提供している。モジュール化されたブロックチェーンインフラストラクチャを提供することで、Cosmosはアプリケーション開発者に利便性を提供し、各自のニーズに合ったパブリックチェーンを選択・利用できるようにしている。

Cosmosエコシステム内のアプリケーションおよびプロトコルはIBC（Inter-Blockchain Communication Protocol）によって接続され、個々の独立したブロックチェーン間でのクロスチェーン連携を実現している。これにより、資産やデータが自由に流通することが可能となる。Cosmosのビジョンは「ブロックチェーンインターネット」を構築し、大量の自律的かつ開発容易なブロックチェーンに対して拡張性と相互作用の可能性を提供することにある。

長年にわたり、CertiKはCosmosエコシステムに対して十分な注目と研究を行ってきた。私たちはCosmosエコシステムのセキュリティ問題について豊富な経験を積んでおり、本研究レポートでは、それらの知見を踏まえ、Cosmos SDKのセキュリティ、IBCプロトコルのセキュリティ、CometBFTのセキュリティ、CosmWasmのセキュリティという4つの方向性に重点を置いて、Cosmosエコシステムのセキュリティに関する探求と研究成果を紹介する。対象はCosmosの基盤コンポーネントから基礎チェーンやアプリケーションチェーンへと広げ、類似の問題を分析・展開することで、読者にチェーン自体に関連するセキュリティ上の要点を下から上へと提示していく。

Cosmosエコシステムの複雑さと多様性により、存在するセキュリティ問題も多様な特徴を持っているため、本レポートではすべての脆弱性タイプを網羅しているわけではない。より典型的な特徴を持ち、Cosmosエコシステムチェーンに対して大きな危害をもたらす可能性のある脆弱性に限定して議論を行う。他のセキュリティ問題について詳しく知りたい方は、CertiKセキュリティエンジニアまでお気軽にご連絡ください。

背景

CometBFT：クロスチェーン拡張性の基盤

CometBFTは革新的な合意アルゴリズムであり、低レイヤーの合意エンジン（CometBFT Core）と汎用アプリケーションブロックチェーンインターフェース（ABCI）という2つの主要コンポーネントから成る。その合意アルゴリズムはPBFT+Bonded PoSのハイブリッド方式を採用しており、ノード間の取引記録の同期を保証している。Interchainの拡張性の核心的構成要素として、CometBFTは検証者による合意を通じて、Interchainエコシステムのセキュリティ、非中央集権性、整合性を維持している。

Cosmos SDK：モジュール化と新機能

Cosmos SDKは、開発者が開発プロセスを加速させるためのツールキットである。モジュール化およびプラグイン可能な特性を備えており、Cosmos SDKを利用することで、開発者はCometBFTの合意アルゴリズムに基づいて独自のブロックチェーンや機能コンポーネントを構築でき、開発の簡便性と開発サイクルの短縮を実現できる。すでにCronos、Kava、最近リリースされたdYdX V4など多くのブロックチェーンプロジェクトで採用されている。今後の開発計画ではモジュール化と新機能の導入に注力し、開発者がより複雑でモジュール化されたアプリケーションを構築できるようにし、より広範で強力なエコシステムを育成していく。

IBCプロトコル：相互運用性と拡張性の強化

IBCプロトコル（Inter-Blockchain Communication Protocol）は、ブロックチェーン間で安全・非中央集権的・許可不要なデータ転送を可能にする。Cosmosは複数の独立かつ並列に動作するブロックチェーンからなる非中央集権ネットワークであり、中継技術を用いて異なるブロックチェーン間のクロスチェーン連携を実現しているため、IBCはプロジェクト全体の核となる部分と言える。Interchain財団は現在、拡張性と可用性という2つのテーマに注目している。IBCの拡張性と相互運用性を高めることで、Cosmosはエコシステムの容量をさらに増大させ、ブロックチェーン、アプリケーション、スマートコントラクト間のシームレスな相互作用を実現する。

CosmWasm：非中央集権的・許可不要なデプロイを解放

CosmWasm（Cosmos WebAssembly）はWebAssemblyベースのスマートコントラクトフレームワークであり、Cosmosエコシステム専用に設計されている。開発者が許可不要の条件下でDAppsをデプロイできるようにするとともに、ブロックチェーン開発者が製品開発サイクルをブロックチェーン開発から切り離せるようにし、バリデータのアップグレードコストを削減できる。その他にもモジュールアーキテクチャ、Cosmos SDKとの統合、クロスチェーン通信などの特性を持つ。

現時点では、Cosmos SDKおよびIBCプロトコルは比較的成熟しており、現在のCosmosエコシステムで最も広く使用されている。

チェーン開発者の観点から見ると、現在Cosmos上で必要な大部分のカスタマイズ機能はCosmos SDKに依存して実現できる。しかし、クロスチェーン操作中の特殊処理やパフォーマンス最適化などの目的で、チェーン開発者はそれぞれのIBCモジュールをカスタマイズすることがある。また、一部のチェーンではCometBFT Coreなどの低レイヤーのエンジンを改変するケースもあるが、本レポートの篇幅の都合上、これらについては取り上げず、ここでは主にCosmos SDKとIBCプロトコルの技術的要点およびセキュリティ問題に焦点を当てる。

Cosmos SDK セキュリティガイド

Cosmos SDKは、ブロックチェーンアプリケーションおよび非中央集権プロトコルの構築に使用される強力で柔軟なフレームワークである。Interchain財団によって開発されたもので、Cosmosネットワークの核となるコンポーネントであり、相互接続されたブロックチェーンの非中央集権ネットワークである。

Cosmos SDKは、カスタムブロックチェーンアプリケーションの開発を簡素化し、異なるブロックチェーン間のシームレスな相互運用性を実現することを目的としている。Cosmos SDKの主な特徴は以下の通り：モジュールアーキテクチャ、カスタマイズ性、CometBFTベース、IBC対応インターフェースの実装、開発者フレンドリー。Cosmos SDKはCometBFT Coreの低レイヤー合意エンジンを活用することで、強固なセキュリティを確保し、ネットワークを悪意ある攻撃から保護し、ユーザーの資産とデータを守っている。また、モジュール性により、ユーザーは簡単にカスタムモジュールを設計できる。これらの利点がある一方で、開発者がCosmos SDKを使用して独自のアプリケーションを実装する際には、依然としてセキュリティの脆弱性が生じる可能性がある。

セキュリティ監査の観点から言えば、監査対象に対して隅々まで配慮し、あらゆる角度からのセキュリティリスクを考慮する必要がある。しかし、セキュリティ研究の観点からは、より大きな影響を及ぼすセキュリティ脆弱性に注目し、短時間で最大のセキュリティリスクを回避し、サービス提供者により効果的な支援を提供することが重要である。この観点から、危険度が高く、影響範囲の大きい脆弱性を分類し、その脆弱性モデルを分析することは極めて必要かつ価値のあることである。

Cosmosエコシステム全体にわたるABCIインターフェースにおいて、我々は特にBeginBlock、EndBlock、CheckTx、DeliverTxの4つのインターフェースに注目する。前者2つは単一ブロックの実行ロジックに直接関係し、後者2つはsdk.Msg（Cosmosエコシステム内でメッセージ伝送の基本データ構造）の具体的な処理に関係している。

Cosmosエコシステムにおける各種アプリケーションチェーンの実装ロジックは、Cosmos SDK内のモジュールやサンプルと同様のパターンに従うため、以下のセキュリティ脆弱性を理解・分析する際には、Cosmos SDKのモジュール実行フローに対する基本的な概念が必要である。

Cosmosエコシステムでは、取引は最初にユーザーエージェント内に作成され、署名されてからブロックチェーン内のノードにブロードキャストされる。ノードはCheckTxメソッドを使用して、署名、送信者の残高、取引シーケンス、提供されたガスなどのさまざまな取引詳細を検証する。取引が検証に合格すれば、メモリプールに追加され、ブロックに含まれるのを待つ。逆に、検証に失敗した場合、ユーザーにエラーメッセージが送られ、取引は拒否される。ブロック実行中には、DeliverTxメソッドによって取引がさらにチェックされ、整合性と決定性が保証される。

Cosmos SDKにおける取引のライフサイクルは、次のように簡潔に説明できる：

1. 取引の作成：取引は、クライアント側で各種ツール、CLI、またはフロントエンドを使用して作成される。

2. メモリプールへの追加：取引はメモリプールに追加され、ノードはアプリケーション層にABCIメッセージ - CheckTxを送信して有効性をチェックし、結果abci.ResponseCheckTxを受け取る。CheckTxでは、取引はバイト形式からTx形式にデコードされ、その後各sdk.Msgに対してValidateBasic()が呼び出され、ステートレスな初歩的な有効性チェックが行われる。アプリケーションに該当するanteHandlerが存在する場合、まずその内部ロジックが実行され、その後runTx関数が呼び出され、最終的にRunMsgs()関数が呼び出されてsdk.Msgの具体的な内容を処理する。CheckTxが成功すれば、メッセージは次のブロック候補としてローカルメモリプールに追加され、P2Pによってピアノードにブロードキャストされる。

3. 提案ブロックへの含め：各ラウンドの開始時に、提案者が最新の取引を含むブロックを作成し、完全ノードが合意の検証者として、そのブロックを受け入れるか空ブロックに投票するかを決定する。

4. ステートの変更：DeliverTxが呼び出され、ブロック内の取引を繰り返し処理する。CheckTxと同様だが、DeliverモードでrunTxが呼び出され、ステートの変更が実行される。MsgServiceRouterが呼び出され、取引内の異なるメッセージを異なるモジュールにルーティングし、それぞれのMsg Server内の対応するメッセージを実行する。その後、メッセージ実行後にチェックが行われ、失敗があればステートはロールバックされる。実行中にはGasメーターを使用して消費されたガス量を追跡する。何らかのガスエラー（例：ガス不足）が発生した場合、実行失敗後の結果と同じとなり、ステートの変更はロールバックされる。

5. ブロックのコミット：ノードが十分な検証者の投票を受け取ると、新しいブロックをブロックチェーンに追加し、アプリケーション層のステート変換を最終確定する。

Cosmosエコシステム上の取引ライフサイクル図

以下はCosmos SDKの具体的な実行ロジックであり、後述の脆弱性トリガー経路の分析時に参照・理解しやすくなる：

Cosmos SDK 重点 ABCI の具体的実行ロジック

一般的な脆弱性分類

脆弱性分類を理解する前に、脆弱性の危険度について基本的な区分が必要である。これにより、危険性の高いセキュリティ脆弱性をよりよく識別し、潜在的なセキュリティリスクを可能な限り回避できる。

危険度と影響範囲を考慮すると、主にCriticalおよびMajor評価のセキュリティ脆弱性に注目すべきである。これらは通常、以下のリスクを引き起こす：

1. チェーンの停止

2. 資金損失

3. システムステートまたは正常動作への影響

そして、これらの危険の原因は、往々にして以下のタイプのセキュリティ脆弱性である：

1. サービス拒否（DoS）

2. 不正なステート設定

3. 検証の欠如または不適切な検証

4. 一意性の問題

5. 合意アルゴリズムの問題

6. 実装上のロジックバグ

7. 言語特有の問題

脆弱性分析

Cosmosエコシステムのモジュール化という特殊性により、さまざまなチェーンの実装においてモジュール間の相互利用やモジュール内の相互呼び出しの事例が多く存在するため、脆弱性のトリガー経路とトリガー変数の制御可能な経路が一致しない場合がある。脆弱性の具体的な原因を分析する際には、トリガー経路だけでなく、脆弱性のキーバリアブルの制御可能な経路にも注目すべきである。これにより、脆弱性モデルをよりよく分類・定義できる。

チェーンの停止

チェーンの停止の主な原因は、ほとんどの場合、単一ブロックの実行中に発生する問題である。しかし、Cosmosの歴史の中で、合意セキュリティの脆弱性により、チェーンが主動的に停止して修復しなければならなかった事例もあった。そのため、ここでは合意タイプのセキュリティ脆弱性もチェーン停止の効果に含めて議論する。これら2つの問題について別々に説明する。

第一のケースは、よく見られるサービス拒否（DoS）タイプの脆弱性であり、主な原因は不適切なクラッシュ処理と、ユーザーが影響を与え得るループ境界を持つ反復操作である。このような脆弱性は、チェーンの停止や速度低下などを引き起こすことが多い。

前述の通り、Cosmos SDKおよびCometBFTはCosmosエコシステムの重要なインフラであり、Cosmosの基礎チェーンだけでなく、さまざまなアプリケーションチェーンもそのアーキテクチャに基づいて自身のロジックを実装している。そのため、これらはすべてCometBFTのABCIインターフェース規則に従う必要があり、攻撃面も主にそのABCIインターフェースに集中している。チェーン停止を引き起こすセキュリティ脆弱性の多くは、ブロックコードの実行に直接影響を与える問題であり、その発生経路は基本的にBeginBlockおよびEndBlockの2つのインターフェースに遡ることができる。

第二のケースは、合意に影響を与える脆弱性であり、通常はさまざまなチェーンの実装に関連している。既知の一般的なものは、ロジック処理の検証、時刻調整、ランダム性の問題などである。このような脆弱性は本質的にブロックチェーンの非中央集権原則に影響を与え、表面上はあまり大きな影響がないように見えるかもしれないが、悪意ある設計者が悪用すれば、依然として大きなセキュリティリスクを生じる可能性がある。

第一のケース

ケース1：SuperNovaプロジェクト

脆弱性背景：鋳造配布操作においてアドレス検証が欠けており、操作失敗や資金流出を引き起こす可能性がある。鋳造モジュールでは、毎回のトークン鋳造は担保額に依存する。しかし、プールが存在しない場合やコントラクトアドレスの入力ミスがある場合、鋳造モジュールが予期しない状態になり、ブロックチェーンの停止を引き起こす可能性がある。報酬プールモジュールでは、プールコントラクトアドレスが検証されていない。配布操作が失敗した場合、チェーンは直ちに停止する。

脆弱性位置：https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/keeper/keeper.go#L175

脆弱性コード断片：

脆弱性トリガー経路：

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

修正パッチ：

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

パッチはmintモジュールではなく、poolincentiveのメッセージ処理モジュール (x/poolincentive/types/msgs.go) に配置されている。

MsgCreateCandidatePool（つまりプール作成）処理時のメッセージに対してアドレス検証を追加し、誤ったアドレスの可能性を根本的に排除しようとしている。

ケース2：Cosmos Interchain Securityプロジェクト

プロジェクトアドレス：https://github.com/cosmos/interchain-security

脆弱性背景：検証者は、同じブロック内で複数のAssignConsumerKeyメッセージを送信することで、提供チェーンの速度を低下させることができる。x/ccv/provider/keeper/key_assignment.goで定義されたAssignConsumerKey関数により、検証者は承認済みのコンシューマーチェーンに対して異なるconsumerKeyを割り当てられる。これを実行するために、consumerAddrsToPrune AddressListに要素が追加される。x/ccv/provider/keeper/relay.goのEndBlockerではこのAddressListを反復処理するため、攻撃者はこれを悪用して提供チェーンの速度を低下させることができる。この攻撃を実行するには、悪意ある行動者が複数のAssignConsumerKeyメッセージを持つ取引を作成し、提供チェーンに送信すればよい。consumerAddrsToPrune AddressListの基数は、送信されたAssignConsumerKeyメッセージの数と同一になる。そのため、EndBlockerの実行に予想よりも多くの時間とリソースがかかり、提供チェーンの動作が遅くなり、あるいは停止する可能性がある。

脆弱性位置：https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378

脆弱性コード断片：

脆弱性トリガー経路：

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

HandleLeadingVSCMaturedPackets

HandleVSCMaturedPacket

PruneKeyAssignments

ケース3：Quicksilverプロジェクト - Airdropモジュール

脆弱性背景：BeginBlockerおよびEndBlockerは、モジュール開発者が自身のモジュール内で実装可能なオプションメソッドである。それぞれ各ブロックの開始時および終了時にトリガーされる。BeginBlockおよびEndBlockメソッド内でクラッシュを使ってエラーを処理すると、エラー発生時にチェーンが停止する可能性がある。EndBlockerが未完了のエアドロップを清算する際に、モジュールが十分なトークンを持っているかどうかを考慮しなかったため、クラッシュが発生し、チェーンが停止する。

脆弱性位置：https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d‍60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15

脆弱性コード断片：

脆弱性トリガー経路：

AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

修正パッチ：https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

panic処理コードを直接削除し、エラーログの記録に変更した。

ケース4：Cosmos Interchain Securityプロジェクト

プロジェクトアドレス：https://github.com/cosmos/interchain-security

脆弱性背景：攻撃者は、提供チェーンの報酬アドレスに複数のトークンを送信することで、サービス拒否攻撃を実行できる。

コンシューマーチェーンのEndBlocker実行フローにおいて、x/ccv/consumer/keeper/distribution.goで定義されたSendRewardsToProvider関数は、tstProviderAddr内のすべてのトークン残高を取得し、それを提供チェーンに送信する。これを実現するためには、報酬アドレスに見つかるすべてのトークンを反復処理し、1つずつIBC経由で提供チェーンに送信する必要がある。誰でも報酬アドレスにトークンを送信できるため、攻撃者は多数の異なるdenomのトークンを生成・送信し、サービス拒否攻撃を仕掛けることができる（例：トークンファクトリーモジュールを持つチェーンを使用）。そのため、EndBlockerの実行に予想よりも多くの時間とリソースがかかり、コンシューマーチェーンの動作が遅くなり、あるいは停止する可能性がある。

脆弱性位置：https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103

脆弱性コード断片：

脆弱性トリガー経路:

AppModule.EndBlock

EndBlock

EndBlockRD

SendRewardsToProvider

第二のケース

このような合意問題は、直感的には深刻な危害をもたらさないかもしれないが、ブロックチェーンの本質的原則やシステム全体、あるいは具体的なシナリオから見ると、その影響や危害は他の通常の脆弱性よりも決して小さくない。また、こうした脆弱性には共通点も存在する。

ケース1

脆弱性背景：Cosmos SDK Security Advisory Jackfruit

Cosmos SDKのx/authzモジュールにおけるValidateBasicメソッドの非決定的挙動は、合意の停止を引き起こしやすい。x/authzモジュールのMsgGrantメッセージ構造には、Grantフィールドが含まれており、これにはユーザー定義の承認に付与された有効期限が含まれる。Grant構造のValidateBasic()検証処理では、ノードのローカルタイムスタンプではなくブロックタイムスタンプを比較すべきところ、ローカルタイムスタンプを比較している。ローカルタイムスタンプは非決定的であり、各ノードのタイムスタンプに差異が生じる可能性があるため、合意問題が発生する。

脆弱性公告：

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319

https://forum.cosmos.network/t/cosmos-sdk-vulnerability-retrospective-security-advisory-jackfruit-october-12-2021/5349

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2

脆弱性コード断片：

修正パッチ：

https://github.com/cosmos/cosmos-sdk/compare/v0.44.1...v0.44.2

タイムスタンプに関するこのような問題は、Cosmos SDKのような基盤コンポーネントだけでなく、さまざまなアプリケーションチェーンでも同様の脆弱性が発生したことがある。

ケース2

脆弱性背景：SuperNova、novaプロジェクト

プロジェクトアドレス：https://github.com/Carina-labs/nova/tree/v0.6.3

time.Now()を使用してOSのタイムスタンプを返している。ローカルタイムは主観的であり、非決定的である。各ノードのタイムスタンプにわずかな差異が生じる可能性があるため、チェーンは合意に達できない可能性がある。ICAControlモジュールでは、取引送信関数がtime.Now()を使用してタイムスタンプを取得している。

脆弱性位置：https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

脆弱性コード断片：

修正パッチ:

ローカルタイムスタンプの使用をブロックタイムスタンプの使用に変更。

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))

ケース3

脆弱性背景：BandChainプロジェクトのオラクルモジュール

プロジェクトアドレス：https://github.com/bandprotocol/bandchain/

コードベースのコメントによると、オラクルモジュールはステーキングの前に行われなければならない。そうすることで、オラクルプロトコル違反者に対するペナルティ措置が可能になる。コード上ではSetOrderEndBlockers関数内で、ステーキングモジュールがオラクルモジュールより先に実行されている。もしステーキングモジュールがオラクルモジュールより先に実行されれば、オラクルモジュール内で行われた検証に基づき、検証者のステーキングを罰するなどの操作は不可能になる。

脆弱性位置：https://github.com/LeastAuthority/bandchain/blob/master/chain/app/app.go#L221-L225

脆弱性コード断片：

脆弱性の具体的な実装とコメントが完全に逆になっていることがわかる。オラクルモジュールはステーキングモジュールより前に来るべきである。

ケース4

脆弱性背景：Sei Cosmosプロジェクトのaccesscontrolモジュール

プロジェクトアドレス：https://github.com/sei-protocol/sei-cosmos

Cosmosのさまざまなコードベースの複数のインスタンスでは、Go言語のmap型を使用し、反復処理している。Go言語のmapの反復処理は非決定的であるため、ノードが異なるステートに到達し、合意問題を引き起こし、チェーンの停止を招く可能性がある。適切な対処法は、マップキーをスライスにソートし、ソートされたキーを反復処理することである。このような問題は比較的一般的であり、言語特有の特性が実装に伴って生じるものである。

x/accesscontrol/keeper/keeper.goのBuildDependencyDag実装では、ノードがanteDepSetを反復処理している。Goのマップ反復の非決定的挙動により、ValidateAccessOpは2種類の異なるエラーを引き起こす可能性があり、これが合意失敗につながる。

脆弱性位置：https://github.com/sei-protocol/sei-cosmos/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9

脆弱性コード断片：

これらのケースからわかるのは、チェーンが受動的に停止するような脆弱性の危害は往々にして最大であるということである。その脆弱性の原因となるロジック関係は、ブロックチェーン内の単一ブロック実行プロセスに直接影響を与えることに遡ることができる。一方、合意セキュリティの脆弱性は、チェーンが主動的に停止して修復するものであり、その原因となるロジック関係は、ブロックチェーン全体の実行プロセスやステートに影響を与えることに遡ることができる。次に議論する資金損失タイプの脆弱性とは焦点が異なり、資金損失タイプの脆弱性は、問題の発生するロジックパスに基づいて具体的な危険度を判断するのではなく、むしろ所有者、資金量、影響範囲、影響方法などに注目する。

資金損失

資金損失問題は、sdk.MsgおよびIBCメッセージのロジック処理においてよく見られる。もちろん、チェーン停止の原因の中にも、チェーンの資金損失を引き起こす可能性のある脆弱性が一部存在するが、具体的な影響は個別の脆弱性による。ここでは前者を中心に議論する。また、IBCはCosmosエコシステムにおいて非常に重要な位置を占めるため、IBCに関連する脆弱性も避けられない。IBCの攻撃面および対応する脆弱性については、次章で詳しく議論する。

資金損失は、ガス消費、資金のロック（引き出し不能）、資金転送中の紛失、計算ロジックエラーによる資金損失、資金保管IDの一意性が保証されていないなどのロジック状況でよく見られる。

ここでSuperNovaプロジェクトを例に、関連する3つの脆弱性を分析する。

脆弱性背景：SuperNovaプロジェクト

プロジェクトアドレス：https://github.com/Carina-labs/nova

ゾーンの小数点以下の桁数が18以上の場合、資金がロックされる可能性がある。プロジェクトのコードでは、ゾーンの小数点以下の桁数に上限がなく、18桁を超えることができる。ClaimSnMesssageでは、ユーザーが自分のシェアトークンを取り戻したい場合、ClaimShareTokenが使用される。しかし、ゾーンの小数点以下の桁数が18以上の場合、変換が失敗し、システムから資産を引き出すことができなくなる。そのため、ゾーンの小数点以下の桁数を制御することで、取引のクラッシュ失敗を直接引き起こすことができる。

脆弱性位置：https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

脆弱性コード断片：

脆弱性トリガー経路：

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

脆弱性背景：SuperNovaプロジェクト

プロジェクトアドレス：https://github.com/Carina-labs/nova/

ゾーンの一意性が検証されていない。登録済みのゾーンでは、ゾーンIDを使用して基本トークン（BaseDenom）の一意性をチェックしている。各ゾーンのBaseDenomは一意であるべきである。もし基本トークンの値が誤って設定された場合、資金損失が生じる。このプロジェクトでは、RegisterZoneで基本トークンを設定する前に、すべてのメインゾーンでBaseDenomが一意であることを確認していない。そのため、同名のBaseDenomを持つ悪意あるゾーンにユーザーが資金を預けてしまう可能性があり、資金損失を引き起こす。

脆弱性位置：https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

脆弱性コード断片：