Philip DiSarro、AikenのCIP-113実装における重大な脆弱性を2件報告

Anastasia Labsの創業者兼CEOでありCIP-143の著者であるPhilip DiSarroは、7月24日、CardanoのCIP-113プログラマブルトークンフレームワークのAiken実装をレビューする中で、重大な脆弱性を2件特定したと7月24日に述べた。同スレッドで、Aikenのコードベースと、DiSarroとInput Outputのチームが開発したオリジナルのPlutarch実装を比較する更新版ベンチマークも公開した。今回の開示は、CIP-113が依然としてLast Check段階にあり、その実装がセキュリティレビューを受けている最中に行われた。

PlutarchはCIP-113ベンチマーク全体でより低コストを記録

公開されたベンチマークファイルは、Cardanoの最大トランザクション予算であるCPU 100億ユニットとメモリ1400万ユニットの下で、両実装を比較している。AikenとPlutarchはいずれも最終的にはUntyped Plutus Coreにコンパイルされ、これはCardanoノードが実行するコードである。

Plutarchは、強調表示された5つの各シナリオすべてで、合計CPUとメモリの消費がより少なかった。

標準的な送金テストでは、AikenはPlutarchに比べてCPUを1.19倍、メモリを1.17倍使用した。表示されたシナリオの中で最大の差は、差し押さえアクションと外部スクリプト、さらに50の公開鍵入力を組み合わせたテストで見られ、AikenはCPUを3.23倍、メモリを2.36倍消費した。

16-swap $NIGHT DEXテストでは、両実装ともCardanoのトランザクション制限内に収まった。Plutarchは利用可能なCPU予算の6.66%とメモリ予算の11.68%を使用し、Aikenはそれぞれ7.59%と15.25%だった。

DiSarroの公開資料には、1件のトランザクションにどれだけの要素を収められるかの線形予測も含まれていた。推計では、入力はPlutarchが658に対しAikenは162、出力はPlutarchが472に対しAikenは334、トークンはPlutarchが36,489に対しAikenは1,661、ポリシーはPlutarchが527に対しAikenは160となった。これらの数値は、本番ネットワークのスループットを測定したものではなく、テストされた実行コストから導かれたスクリプト容量の予測値である。

コンパイル済みスクリプトの比較では、7つのカテゴリのうち6つでPlutarchのスクリプトサイズが小さかった。directoryNodeSpendingスクリプトは、Plutarchで331バイト、Aikenで1,698バイトだった。例外はprogrammableLogicGlobalで、Aikenは3,157バイトのスクリプトを生成し、Plutarchは3,437バイトだった。

CIP-113はCardanoネイティブ資産にプログラム可能なルールを追加する

CIP-113は、台帳の変更やハードフォークを必要とせずに、Cardanoのネイティブ資産にプログラム可能な検証ルールを追加するためのフレームワークを提案する。発行者は、トークンの送金、ミンティング、バーンの際に実行される条件を定義できる。

ルールには、許可リスト、拒否リスト、送金制限、タイムロック、任意の凍結または差し押さえ機能を含めることができる。このフレームワークは、所有権や移転に関する管理が必要なステーブルコイン、有価証券のトークン化、実世界資産を想定している。

提案されたアーキテクチャでは、プログラム可能トークンは共有のスマートコントラクトアドレスに保管され、所有権はステーク資格情報によって表現される。オンチェーン登録簿が、各トークンポリシーをその移転ルール、発行ロジック、および権限を与えられた第三者のコントロールと結び付ける。

ウォレットは、残高を正しく表示するためにステーク資格情報を解決する必要がある。分散型取引所、インデクサ、エクスプローラやその他のアプリケーションも、ユーザーが既存のCardanoインフラを通じてプログラム可能トークンとやり取りできるようにする前に、追加の検証プロセスをサポートする必要がある。

AikenとPlutarchは、同じオンチェーンのコード形式にコンパイルされる一方で、異なる開発アプローチを提供する。Cardanoの開発者向けドキュメントでは、Aikenは統合テストと目的志向の構文を備えた取り組みやすい出発点として紹介されている。PlutarchはHaskellベースの組み込み言語であり、生成されるコードや実行コストをより詳細に制御できるようにする。

DiSarroはCIP-143, Interoperable Programmable Tokensを執筆し、そのオリジナルのPlutarchリファレンス実装でInput Outputのチームと協働した。Cardano Foundationのリポジトリによれば、現在のAikenバリデータはその実装から移行され、より広範なCIP-113フレームワークに合わせて適応されたという。

彼が元のアーキテクチャとコードベースに直接関与していたことから、新たなベンチマーク比較は本プロジェクトの開発史の文脈に位置付けられる。CIP-143は候補であるCIP-113に取り込まれた後に非アクティブとしてマークされており、CIP-113はCIP編集者によるLast Checkのレビュー段階にとどまっている。

報告された2件の脆弱性は技術的な開示を待っている

DiSarroは、Aiken実装のレビューで監査プロセスでは見落とされていた重大な脆弱性を2件発見したと述べた。彼のスレッドでは、影響を受けるコード、想定される攻撃経路、潜在的な影響、是正状況は特定されていない。

リポジトリにはすでに初回監査からの公開済み所見が含まれており、重大とラベル付けされたクローズドイシューが2件ある。Issue 56は、第三者アクションの最中に新規ミントされたトークンがプログラム可能な管理外へと逃れる経路を記述していた。Issue 64は、同じ管理機能によって無関係なUTxOが汚染され得る可能性に対処していた。

これらの所見は初回監査の際に報告されたものであり、さらなる技術的開示がない限り、DiSarroがその後に発見した2件の脆弱性と同一とは特定できない。

セキュリティ上の懸念は、CIP-113のレビュー議論の中でも提起されている。あるコントリビューターは7月20日に、複数の高深刻度の脆弱性が見落とされており、提案された使い勝手向上の一部が追加のセキュリティ問題を招いていると述べた。その後のCIPレビューでは、提案がLast Checkにある間に、次のステップとしてより包括的な監査を含めるべきだという認識で参加者が一致した。

Cardano Foundationのリポジトリは、初回監査および追随する再監査の所見がメインブランチで修正済みであると記している。しかし最終監査報告書は未公表であり、当該実装は、その報告書の公表に加えて、より広範なテストとさらなる専門家レビューが完了するまで、実資産での本番利用には不適切であると指定されている。

CIP-113の実装が実資産での展開に進む前に、具体的な成果物が3点未了である。最終監査報告書の公表、DiSarroが報告した2件の脆弱性の開示と修正、CIPプロセスの中で要請されたより広範なセキュリティレビューの完了である。これらの成果物が、提案のマージ前に取り込まれるコードや仕様変更の内容を定義し、当該実装が本番利用の検討対象となるかを左右する。